new/ resize

Discussion in 'C++' started by machine99, Oct 20, 2003.

  1. machine99

    machine99 Guest

    how do you resize an array allocated with new?
     
    machine99, Oct 20, 2003
    #1
    1. Advertising

  2. machine99

    Rolf Magnus Guest

    machine99 wrote:

    > how do you resize an array allocated with new?


    You don't. Yo have to allocate a new block of memory of the target size
    and then move the data there and deallocate the original array.
    Any reason why you don't use std::vector, which handles resizing for
    you?
     
    Rolf Magnus, Oct 20, 2003
    #2
    1. Advertising

  3. machine99

    machine99 Guest

    > > how do you resize an array allocated with new?
    >
    > You don't. Yo have to allocate a new block of memory of the target size
    > and then move the data there and deallocate the original array.
    > Any reason why you don't use std::vector, which handles resizing for
    > you?


    I do use std::vector quite extensively but there will always be special
    cases :)
     
    machine99, Oct 20, 2003
    #3
  4. machine99 wrote:
    >>>how do you resize an array allocated with new?

    >>
    >>You don't. Yo have to allocate a new block of memory of the target size
    >>and then move the data there and deallocate the original array.
    >>Any reason why you don't use std::vector, which handles resizing for
    >>you?

    >
    >
    > I do use std::vector quite extensively but there will always be special
    > cases :)


    Actually, the situations where an array is preferred or required
    over a std::vector are few and don't require resizing.

    Some of these situations are code / memory space and execution time.
    However, time spent developing (and development cost) usually
    outweighs any premature optimization issues and all problems
    involved with an array when a std::vector should have been used.

    The programming priorities (listed with highest priority first):
    1. Quality & robustness
    2. Development time (also related to cost).
    3. User interaction or interaction with the environment.
    4. Code space and execution time (i.e. optimization).
    If a program can't correctly turn a motor, turning it faster
    or using less code to turn it is a mute point.

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    http://www.sgi.com/tech/stl -- Standard Template Library
     
    Thomas Matthews, Oct 20, 2003
    #4
  5. Thomas Matthews wrote:
    > machine99 wrote:
    >
    >>>> how do you resize an array allocated with new?
    >>>
    >>>
    >>> You don't. Yo have to allocate a new block of memory of the target size
    >>> and then move the data there and deallocate the original array.
    >>> Any reason why you don't use std::vector, which handles resizing for
    >>> you?

    >>
    >>
    >>
    >> I do use std::vector quite extensively but there will always be special
    >> cases :)

    >
    >
    > Actually, the situations where an array is preferred or required
    > over a std::vector are few and don't require resizing.
    >
    > Some of these situations are code / memory space and execution time.
    > However, time spent developing (and development cost) usually
    > outweighs any premature optimization issues and all problems
    > involved with an array when a std::vector should have been used.
    >
    > The programming priorities (listed with highest priority first):
    > 1. Quality & robustness
    > 2. Development time (also related to cost).
    > 3. User interaction or interaction with the environment.
    > 4. Code space and execution time (i.e. optimization).
    > If a program can't correctly turn a motor, turning it faster
    > or using less code to turn it is a mute point.
    >


    Oops, that should be "moot point".

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    http://www.sgi.com/tech/stl -- Standard Template Library
     
    Thomas Matthews, Oct 20, 2003
    #5
  6. machine99

    Howard Guest

    "Thomas Matthews" <> wrote in
    message news:...
    > machine99 wrote:
    > >>>how do you resize an array allocated with new?
    > >>
    > >>You don't. Yo have to allocate a new block of memory of the target size
    > >>and then move the data there and deallocate the original array.
    > >>Any reason why you don't use std::vector, which handles resizing for
    > >>you?

    > >
    > >
    > > I do use std::vector quite extensively but there will always be special
    > > cases :)

    >
    > Actually, the situations where an array is preferred or required
    > over a std::vector are few and don't require resizing.
    >


    Why does the need to resize an array mean that it is no longer neccessary to
    use an array instead of a vector?

    > Some of these situations are code / memory space and execution time.
    > However, time spent developing (and development cost) usually
    > outweighs any premature optimization issues and all problems
    > involved with an array when a std::vector should have been used.
    >
    > The programming priorities (listed with highest priority first):
    > 1. Quality & robustness
    > 2. Development time (also related to cost).
    > 3. User interaction or interaction with the environment.
    > 4. Code space and execution time (i.e. optimization).
    > If a program can't correctly turn a motor, turning it faster
    > or using less code to turn it is a mute point.
    >
    > --


    You're missing one of the most important priorities for many of us:
    compatibility with existing code. We don't all get to choose how we would
    write code. Much of it is forced upon us by what was written before, (or by
    what our operating system or third-party API's require).

    -Howard
     
    Howard, Oct 20, 2003
    #6
  7. "Howard" wrote:

    >
    > "Thomas Matthews" <>
    > wrote in message news:...
    > > machine99 wrote:

    [snip]
    > You're missing one of the most important priorities for many of us:
    > compatibility with existing code. We don't all get to choose how we
    > would write code. Much of it is forced upon us by what was written
    > before, (or by what our operating system or third-party API's
    > require).
    >
    > -Howard
    >
    >

    When it comes to a point where compatibility to arrays comes into the
    game, I usually stick with std::vector, as I can easily pass the content
    of a vector into a legacy function (&vector[0]) and converting a
    returned array into a vector normally doesn't affect performance in the
    stuff that I do. (If it does and it was proven by a profiler, then that
    is another story!)
    --
    To mail me directly, remove the NO*SPAM parts in
    NO**SPAM
     
    Andreas =?ISO-8859-1?Q?M=FCller?=, Oct 20, 2003
    #7
  8. Howard wrote:

    > "Thomas Matthews" <> wrote in
    > message news:...
    >
    > Why does the need to resize an array mean that it is no longer neccessary to
    > use an array instead of a vector?


    IMHO, the primary difference between a vector and an array is the
    resizing issue. By the C++ definition, an array is a static structure
    in that its size doesn't change. If the array size changes, then a
    vector is a better choice (since the code already exists for
    resizing and has been tested). There are other qualities of a
    vector, such as bounds checking, that are useful during the
    development stage.

    >
    >
    >>Some of these situations are code / memory space and execution time.
    >>However, time spent developing (and development cost) usually
    >>outweighs any premature optimization issues and all problems
    >>involved with an array when a std::vector should have been used.
    >>
    >>The programming priorities (listed with highest priority first):
    >> 1. Quality & robustness
    >> 2. Development time (also related to cost).
    >> 3. User interaction or interaction with the environment.
    >> 4. Code space and execution time (i.e. optimization).
    >>If a program can't correctly turn a motor, turning it faster
    >>or using less code to turn it is a mute point.
    >>
    >>--

    >
    >
    > You're missing one of the most important priorities for many of us:
    > compatibility with existing code. We don't all get to choose how we would
    > write code. Much of it is forced upon us by what was written before, (or by
    > what our operating system or third-party API's require).
    >
    > -Howard


    I still believe that quality and robustness is top priority especially
    when maintaining legacy systems. I know from personal experience that
    small changes can cause an existing system to blow up (primarily due
    to undocumented dependencies).

    Don't get me wrong, compatibility is an issue. A correct modification
    that takes more time to develop is better than a quick and dirty fix
    that isn't 100% correct. Also, if the new code is not compatible
    with the existing code, it is worthless. I would place compatibility
    under quality and robustness.

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
     
    Thomas Matthews, Oct 20, 2003
    #8
  9. machine99

    machine99 Guest

    How does std::vector resize then?

    Perhaps I could access its memory functions/classes/whatever and use them
    for my own purpose?
     
    machine99, Oct 21, 2003
    #9
  10. Rolf Magnus <> spoke thus:

    > You don't. Yo have to allocate a new block of memory of the target size
    > and then move the data there and deallocate the original array.
    > Any reason why you don't use std::vector, which handles resizing for
    > you?


    Just for curiosity's sake, why isn't there something like realloc() for new?
    Wouldn't that make situations like this one easier to manage?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 21, 2003
    #10
  11. machine99

    Rolf Magnus Guest

    Christopher Benson-Manica wrote:

    > Rolf Magnus <> spoke thus:
    >
    >> You don't. Yo have to allocate a new block of memory of the target
    >> size and then move the data there and deallocate the original array.
    >> Any reason why you don't use std::vector, which handles resizing for
    >> you?

    >
    > Just for curiosity's sake, why isn't there something like realloc()
    > for new? Wouldn't that make situations like this one easier to manage?


    For POD types maybe, but if you have "real" classes with constructors,
    virtual functions "and stuff", it's not so easy anymore.
    Also note that realloc() also uses the "allocate-copy-delete" way.
    OTOH, C++ more or less has that functionality, but it's built into
    std::vector.
     
    Rolf Magnus, Oct 21, 2003
    #11
  12. machine99

    Jon Bell Guest

    In article <bn3863$41d$>,
    Christopher Benson-Manica <> wrote:
    >
    >Just for curiosity's sake, why isn't there something like realloc() for new?


    There's been a *huge* thread recently in comp.lang.c++.moderated about
    this during the past month. I suggest that you look it up in Google
    Groups. Use the "Advanced Groups Search", restrict your search to
    c.l.c++.m, and search for "realloc".

    --
    Jon Bell <> Presbyterian College
    Dept. of Physics and Computer Science Clinton, South Carolina USA
     
    Jon Bell, Oct 21, 2003
    #12
  13. machine99

    Howard Guest

    "Andreas Müller" <> wrote in message
    news:bn0vj8$rri5o$-

    > When it comes to a point where compatibility to arrays comes into the
    > game, I usually stick with std::vector, as I can easily pass the content
    > of a vector into a legacy function (&vector[0]) and converting a
    > returned array into a vector normally doesn't affect performance in the
    > stuff that I do. (If it does and it was proven by a profiler, then that
    > is another story!)
    > --


    I wasn't aware you could do that. Is the memory for the objects stored in
    the vector guaranteeed to be contiguous? If so, that would definitely allow
    me to use vectors in some places where I've avoided them. But how does the
    vector handle the case where re-sizing has moved the data in memory?
    Overriding the [] (or &) operator?

    -Howard
     
    Howard, Oct 21, 2003
    #13
  14. > > When it comes to a point where compatibility to arrays comes into
    the
    > > game, I usually stick with std::vector, as I can easily pass the

    content
    > > of a vector into a legacy function (&vector[0]) and converting a
    > > returned array into a vector normally doesn't affect performance in

    the
    > > stuff that I do. (If it does and it was proven by a profiler, then

    that
    > > is another story!)

    >
    > I wasn't aware you could do that. Is the memory for the objects

    stored in
    > the vector guaranteeed to be contiguous?


    Officially not (yet). Practically yes.

    > If so, that would definitely allow
    > me to use vectors in some places where I've avoided them. But how

    does the
    > vector handle the case where re-sizing has moved the data in memory?
    > Overriding the [] (or &) operator?


    In that case the address obtained with &vector[0] before the resize is
    no longer valid (to be more precise not guaranteed to be valid), just
    like iterators get invalidated when the vector is changed. Because
    std::vector overloads the [] operator, moving of the actual objects in
    memory is invisible to the user.

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
     
    Peter van Merkerk, Oct 21, 2003
    #14
  15. Howard wrote:
    >
    > "Andreas Müller" <> wrote in message
    > news:bn0vj8$rri5o$-
    >
    > > When it comes to a point where compatibility to arrays comes into the
    > > game, I usually stick with std::vector, as I can easily pass the content
    > > of a vector into a legacy function (&vector[0]) and converting a
    > > returned array into a vector normally doesn't affect performance in the
    > > stuff that I do. (If it does and it was proven by a profiler, then that
    > > is another story!)
    > > --

    >
    > I wasn't aware you could do that. Is the memory for the objects stored in
    > the vector guaranteeed to be contiguous?


    Strictly speaking it is not guaranteed.
    But most people feel that it has to be that way and some forced properties
    of std::vector force the memory to be practically contiguos. Practically there
    is no known implementation which hasn't contigous memory.
    That said: There is a defect report on this issue and as far as I know
    the next standard will contain the critical sentence.

    > If so, that would definitely allow
    > me to use vectors in some places where I've avoided them. But how does the
    > vector handle the case where re-sizing has moved the data in memory?
    > Overriding the [] (or &) operator?


    Yep. It's a simple exercise.

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Oct 21, 2003
    #15
  16. machine99

    Ron Natalie Guest

    "Howard" <> wrote in message news:bn3g9a$...

    >
    > I wasn't aware you could do that. Is the memory for the objects stored in
    > the vector guaranteeed to be contiguous? If so, that would definitely allow
    > me to use vectors in some places where I've avoided them. But how does the
    > vector handle the case where re-sizing has moved the data in memory?
    > Overriding the [] (or &) operator?


    Technically the standard is mute on the subject, but you can sort of intuit that it
    has to be. This will be corrected in the TC1. Nobody knows of any implementations
    that don't do it "right."

    The value of the address of the internal array is not valid after any capacity changes.
     
    Ron Natalie, Oct 21, 2003
    #16
  17. machine99

    Jim West Guest

    In article <3f954aef$0$171$>, Ron Natalie wrote:
    >
    > "Howard" <> wrote in message news:bn3g9a$...
    >
    >>
    >> I wasn't aware you could do that. Is the memory for the objects stored in
    >> the vector guaranteeed to be contiguous? If so, that would definitely allow
    >> me to use vectors in some places where I've avoided them. But how does the
    >> vector handle the case where re-sizing has moved the data in memory?
    >> Overriding the [] (or &) operator?

    >
    > Technically the standard is mute on the subject, but you can sort of intuit that it
    > has to be. This will be corrected in the TC1. Nobody knows of any implementations
    > that don't do it "right."
    >


    Hmmm...I was warned away from doing this recently becaus it is non-
    standard. However, I found that valarray met most of my needs since it is
    guaranteed to be in contiguous memory and it has a resize function (although
    data is lost). As I only resize when the data changes completely
    (computational electromagnetics), this is not a problem. I may switch
    certain things over to vector, however, if it really is safe.
     
    Jim West, Oct 23, 2003
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eldon Lei [MSFT]
    Replies:
    0
    Views:
    637
    Eldon Lei [MSFT]
    Jul 10, 2003
  2. Alexandre Martins

    IMAGE RESIZE

    Alexandre Martins, Aug 13, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    394
    Alexandre Martins
    Aug 13, 2003
  3. Replies:
    1
    Views:
    4,003
    =?Utf-8?B?QmluIFNvbmcsIE1DUA==?=
    Apr 22, 2004
  4. Replies:
    2
    Views:
    1,266
    Adrienne
    Feb 13, 2005
  5. Replies:
    2
    Views:
    470
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page