are container elements on the stack or heap

Discussion in 'C++' started by Anjo Gasa, Apr 25, 2006.

  1. Anjo Gasa

    Anjo Gasa Guest

    Let's say I have:

    std::vector<Object> rgObjects;

    rgObjects itself is declared as a local variable and hence on the
    stack. But what about as I add elements to rgObjects:

    Object newObject( 3, 4 );
    rgObjects.push_back( newObject );

    newObject itself isn't placed on the vector, rather the copy
    constructor is called, and an object copied with its values is placed
    on the vector. Does this new instance of Object reside on the stack or
    the heap.

    Anjo
     
    Anjo Gasa, Apr 25, 2006
    #1
    1. Advertising

  2. * Anjo Gasa:
    > Let's say I have:
    >
    > std::vector<Object> rgObjects;
    >
    > rgObjects itself is declared as a local variable and hence on the
    > stack. But what about as I add elements to rgObjects:
    >
    > Object newObject( 3, 4 );
    > rgObjects.push_back( newObject );
    >
    > newObject itself isn't placed on the vector, rather the copy
    > constructor is called, and an object copied with its values is placed
    > on the vector. Does this new instance of Object reside on the stack or
    > the heap.


    C++ has no notion of stack or heap: that's an implementation aspect.

    That said, the copy might reside in dynamically allocated memory or not,
    depending on the implementation of std::vector, the current size of the
    vector, and e.g. the phase of the moon.

    Why do you want to know?

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Apr 25, 2006
    #2
    1. Advertising

  3. In article <>,
    "Anjo Gasa" <> wrote:

    > Let's say I have:
    >
    > std::vector<Object> rgObjects;
    >
    > rgObjects itself is declared as a local variable and hence on the
    > stack. But what about as I add elements to rgObjects:
    >
    > Object newObject( 3, 4 );
    > rgObjects.push_back( newObject );
    >
    > newObject itself isn't placed on the vector, rather the copy
    > constructor is called, and an object copied with its values is placed
    > on the vector. Does this new instance of Object reside on the stack or
    > the heap.
    >
    > Anjo


    The heap.

    -Howard
     
    Howard Hinnant, Apr 25, 2006
    #3
  4. Anjo Gasa

    noone Guest

    On Tue, 25 Apr 2006 07:54:51 -0700, Anjo Gasa wrote:

    > Let's say I have:
    >
    > std::vector<Object> rgObjects;
    >
    > rgObjects itself is declared as a local variable and hence on the stack.
    > But what about as I add elements to rgObjects:
    >
    > Object newObject( 3, 4 );
    > rgObjects.push_back( newObject );
    >
    > newObject itself isn't placed on the vector, rather the copy constructor
    > is called, and an object copied with its values is placed on the vector.
    > Does this new instance of Object reside on the stack or the heap.


    AFAIK, the only requirement to the vector is that its objects occupy
    consecutive memory locations so that accessing the elements as an array is
    possible. Think about what you're asking though. What is the typical
    size of a stack frame compared to the free memory (heap). Why would
    anyone implement such a generic container to use stack space? There may
    be some special implementation where the space is on the stack but I don't
    think they are too common.

    -noone of consequence
     
    noone, Apr 26, 2006
    #4
  5. Anjo Gasa

    Guest

    Alf P. Steinbach wrote:
    > * Anjo Gasa:
    > > Let's say I have:
    > >
    > > std::vector<Object> rgObjects;
    > >
    > > rgObjects itself is declared as a local variable and hence on the
    > > stack. But what about as I add elements to rgObjects:
    > >
    > > Object newObject( 3, 4 );
    > > rgObjects.push_back( newObject );
    > >
    > > newObject itself isn't placed on the vector, rather the copy
    > > constructor is called, and an object copied with its values is placed
    > > on the vector. Does this new instance of Object reside on the stack or
    > > the heap.

    >
    > ... the copy might reside in dynamically allocated memory or not,
    > depending on the implementation of std::vector, the current size of the
    > vector, and e.g. the phase of the moon.


    I don't think the default allocator has such liberty (and Anjo didn't
    override it)
    so the copy will reside in memory dynamically allocated by the default
    allocator.

    HTH,
    Michiel Salters
     
    , Apr 26, 2006
    #5
  6. * :
    > Alf P. Steinbach wrote:
    >> * Anjo Gasa:
    >>> Let's say I have:
    >>>
    >>> std::vector<Object> rgObjects;
    >>>
    >>> rgObjects itself is declared as a local variable and hence on the
    >>> stack. But what about as I add elements to rgObjects:
    >>>
    >>> Object newObject( 3, 4 );
    >>> rgObjects.push_back( newObject );
    >>>
    >>> newObject itself isn't placed on the vector, rather the copy
    >>> constructor is called, and an object copied with its values is placed
    >>> on the vector. Does this new instance of Object reside on the stack or
    >>> the heap.

    >> ... the copy might reside in dynamically allocated memory or not,
    >> depending on the implementation of std::vector, the current size of the
    >> vector, and e.g. the phase of the moon.

    >
    > I don't think the default allocator has such liberty (and Anjo didn't
    > override it)
    > so the copy will reside in memory dynamically allocated by the default
    > allocator.


    That's news to me.

    It would mean that the standard disallows small-size optimization using
    a fixed buffer, or that there is a fundamental difference in those
    requirements for std::basic_string and std::vector (apart from
    contigousness, which now is solved).

    I don't think there is such a difference -- and if there is, it would
    be a defect in the standard.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Apr 26, 2006
    #6
    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. Wolfgang Lipp
    Replies:
    1
    Views:
    412
    Patrick TJ McPhee
    Jan 30, 2004
  2. Wolfgang Lipp
    Replies:
    0
    Views:
    491
    Wolfgang Lipp
    Jan 28, 2004
  3. Replies:
    4
    Views:
    815
    Daniel T.
    Feb 16, 2006
  4. Michal Slocinski

    Heap dump file size vs heap size

    Michal Slocinski, Mar 25, 2008, in forum: Java
    Replies:
    1
    Views:
    755
    GArlington
    Mar 25, 2008
  5. Hicham Mouline
    Replies:
    1
    Views:
    407
    Kai-Uwe Bux
    Apr 11, 2010
Loading...

Share This Page