are container elements on the stack or heap

A

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.

Anjo
 
A

Alf P. Steinbach

* 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?
 
H

Howard Hinnant

"Anjo Gasa said:
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
 
N

noone

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
 
M

Michiel.Salters

Alf said:
* Anjo Gasa:

... 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
 
A

Alf P. Steinbach

* (e-mail address removed):
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top