Creating dynamically allocating abjects with "new"keyword

Discussion in 'C++' started by conceptualtechnologist@gmail.com, Oct 11, 2011.

  1. Guest

    Is it OK to create dynamically allocating objects with new keyword ? for example consider std::vector i.e. pointer = new std::vector
    if I add many objects to vector, then it may need to copy itself to another location of RAM. then pointer value is no longer correct. how can I access the object then ?
     
    , Oct 11, 2011
    #1
    1. Advertising

  2. Goran Guest

    On Oct 11, 3:45 pm, wrote:
    > Is it OK to create dynamically allocating objects with new keyword ? for example consider std::vector i.e. pointer = new std::vector


    This is OK. You have to eventually call delete on "pointer".

    > if I add many objects to vector, then it may need to copy itself to another location of RAM. then pointer value is no longer correct. how can I access the object then ?


    There's no such thing as a pointed-to object (like your vector)
    "moving itself" to another location. You might be thinking about
    vector moving it's (internal) contents to another location. That will
    invalidate pointers to objects __inside__ the vector that you might
    hold, but not the pointer to the vector itself.

    It would be best that you show exact, compilable code snippet that
    somehow represents your doubts.

    Goran.
     
    Goran, Oct 11, 2011
    #2
    1. Advertising

  3. On 10/11/2011 9:45 AM, wrote:
    > Is it OK to create dynamically allocating objects with new keyword ?
    > for example consider std::vector i.e. pointer = new std::vector if I
    > add many objects to vector


    Yes, there is no special provision about that in the Standard.

    A nitpick: there is no type 'std::vector', it's a template. If you need
    to create an object, you need a concrete type. For instance, to create
    a dynamic standard vector of ints, you can do 'new std::vector<int>'.

    >, then it may need to copy itself to
    > another location of RAM.


    Objects cannot copy themselves. 'this' pointer is non-assignable.

    > then pointer value is no longer correct.


    I don't understand what you're trying to say.

    Standard containers manage their own dynamic memory. It does not matter
    where the object itself lives. The two locations (of the container
    object and of its contained items) are independent. Standard vector
    keeps its elements in an array allocated in the freestore (using new[]
    operator).

    > how
    > can I access the object then ?


    The same way you always access the object.

    If you're experiencing some kind of a problem, get to it. If you're
    trying to theorise about what would happen to a vector's storage if the
    vector itself moves from one place in memory to another, which is OK if
    it's dynamically allocated, then there is nothing to worry about. As I
    said before, the storage for the vector's elements and the storage for
    the vector itself are *independent*. Moving one does not invalidate the
    other. That's how you can have vectors or vectors.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 11, 2011
    #3
  4. Guest

    Thank Goran and Leigh and Victor

    Well my codes are in MFC(VC++) not stdlib and it is very big. actually std:vector was just an example and I have a class that I want to store its instances in a map(more exactly CMap). the class is very big(has lots of CArrays(counterpart of std::vector) and accepts data from a device and amount ofdata can be really high(maybe some 10s MB after some time). so I thought is it a good way to store them in CMap. I have used map because I want to find objects very fast by their key, because packets may come from device with high speed and I need to dispatch them to the right object.
    Your explanations was very helpful and almost made me sure that there is nothing to worry. only one thing if a class like std::vector has an internal array that stores address or value of its objects, what happens when that internal array grows so much that it needs to be relocated. I mean will the std::vector breaks the internal array in parts or can move even internal array to another location ( <b> in addition to moving the contents of internal array </b>) and keeps the base object in the place first returned by the "new" keyword ?
     
    , Oct 11, 2011
    #4
  5. On 10/11/2011 1:32 PM, wrote:
    > [..]
    > explanations was very helpful and almost made me sure that there is
    > nothing to worry. only one thing if a class like std::vector has an
    > internal array that stores address or value of its objects, what
    > happens when that internal array grows so much that it needs to be
    > relocated.


    It gets reallocated.

    > I mean will the std::vector breaks the internal array in
    > parts


    No.

    > or can move even internal array to another location (<b> in
    > addition to moving the contents of internal array</b>) and keeps the
    > base object in the place first returned by the "new" keyword ?


    I don't know what you mean by 'base object', sorry. Yes, the [internal]
    array is fully reallocated in another place, just to keep being
    contiguous, which is a requirement.

    There are several implementations of 'std::vector' that are available on
    the 'net. Just take a look how they work, and many questions are going
    to be answered. Even your compiler's implementation is likely fully
    open for studying.

    Also, find a decent book on Standard Library (Nicolai Josuttis has
    written a wonderful, albeit rather large, one), and read it.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 11, 2011
    #5
  6. none Guest

    In article <>,
    Leigh Johnston <> wrote:
    >On 11/10/2011 14:45, wrote:
    >> Is it OK to create dynamically allocating objects with new keyword ? for example consider std::vector i.e.

    >pointer = new std::vector
    >> if I add many objects to vector, then it may need to copy itself to another location of RAM. then pointer

    >value is no longer correct. how can I access the object then ?
    >
    >There is no need to allocate a std::vector object with new as the vector
    >itself contains its own pointer to the allocated elements also called
    >the "controlled sequence".


    Well, if you want to std::vector object lifetime to goes beyond
    current scope, you probably should allocate the std::vector object
    with new.

    However, you do not need to allocate the std::vector with new if you
    just don't want to put a lot of data on the stack. As Leigh describe,
    the std::vector will own a controlled sequence and the data will be in
    freestore (often referred to as "heap" although this is not the
    official word used in the C++ standard)

    >A vector does not copy "itself" when you add
    >many elements; it may however need to reallocate the controlled sequence
    >depending on what the current capacity() of the vector is.


    Exactly, the vector is perfectly allowed to move the location of its
    controlled sequence (where the data is) but it will never move itself
    of its free-will

    Yannick
     
    none, Oct 17, 2011
    #6
  7. Paavo Helde <> wrote:
    > std::vector can be passed around by value, which is fine most of the times;
    > if performance suffers, one can replace passing-by-value by swap()-ing out
    > the vector content from the current scope, or use C++0x move constructors.
    > No need to use any pointers or dynamic allocation here.


    I wish there were official versions of all containers that explicitly
    use reference counting instead of deep copying. They could be named like
    std::shared_vector, std::shared_list, std::shared_map and so on (in the
    same vein as std::shared_ptr).
     
    Juha Nieminen, Oct 18, 2011
    #7
  8. gwowen Guest

    Paavo Helde wrote:

    > std::vector can be passed around by value, which is fine most of the times;


    [citation needed]
     
    gwowen, Oct 18, 2011
    #8
  9. gwowen <> wrote:
    > Paavo Helde wrote:
    >
    >> std::vector can be passed around by value, which is fine most of the times;

    >
    > [citation needed]


    Citation to what? That it can be passed by value, or that it's "fine
    most of the times"? (The former is a fact, the latter is an opinion.)
     
    Juha Nieminen, Oct 18, 2011
    #9
  10. gwowen Guest

    On Oct 18, 2:36 pm, Juha Nieminen <> wrote:
    > gwowen <> wrote:
    > > Paavo Helde wrote:

    >
    > >> std::vector can be passed around by value, which is fine most of the times;

    >
    > > [citation needed]

    >
    >   Citation to what? That it can be passed by value, or that it's "fine
    > most of the times"? (The former is a fact, the latter is an opinion.)


    Well, you know, some sort of evidence or measurements that caused you
    to form the opinion that its "fine most of the times". Do common
    implementations reference count, or are you claiming that deep copies
    are fine "most of the times"?
     
    gwowen, Oct 18, 2011
    #10
  11. On 10/18/2011 11:20 AM, gwowen wrote:
    > On Oct 18, 2:36 pm, Juha Nieminen<> wrote:
    >> gwowen<> wrote:
    >>> Paavo Helde wrote:

    >>
    >>>> std::vector can be passed around by value, which is fine most of the times;

    >>
    >>> [citation needed]

    >>
    >> Citation to what? That it can be passed by value, or that it's "fine
    >> most of the times"? (The former is a fact, the latter is an opinion.)

    >
    > Well, you know, some sort of evidence or measurements that caused you
    > to form the opinion that its "fine most of the times". Do common
    > implementations reference count, or are you claiming that deep copies
    > are fine "most of the times"?


    If we set aside your mutual desire to have your daily sparring match,
    then the original claim about passing "around" by value is bogus, of
    course, unless only one side of it is considered - returning by value -
    which is often "fine" if RVO is in effect. Passing *into* a function
    should be done by ref to const to *avoid* performance problems, of course.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Oct 18, 2011
    #11
    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. Joe Estock
    Replies:
    7
    Views:
    367
    Karl Heinz Buchegger
    Nov 18, 2003
  2. dynamically allocating a 2d array

    , Sep 10, 2005, in forum: C Programming
    Replies:
    10
    Views:
    685
    Barry Schwarz
    Sep 13, 2005
  3. Replies:
    6
    Views:
    458
    Peter Otten
    May 10, 2007
  4. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    356
  5. Rakesh Kumar
    Replies:
    5
    Views:
    686
    James Kanze
    Dec 21, 2007
Loading...

Share This Page