By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,306 Members | 1,657 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,306 IT Pros & Developers. It's quick & easy.

are container elements on the stack or heap

P: n/a
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

Apr 25 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/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.


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?
Apr 25 '06 #2

P: n/a
In article <11**********************@e56g2000cwe.googlegroups .com>,
"Anjo Gasa" <an******@gmail.com> 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
Apr 25 '06 #3

P: n/a
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

Apr 26 '06 #4

P: n/a
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 '06 #5

P: n/a
* Mi*************@tomtom.com:
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?
Apr 26 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.