stack or heap for C++ object

[moongeegee]

How to determine we should use either stack/static storage or heap for
C++ objects.
I know there are pro and con between stack/static storage and heap.
If I have a program which is written by other programmers, how to
detect whether the program
use stack or heap.
Thanks in advance.

 

[Jonathan Lee]

How to determine we should use either stack/static storage or heap for

C++ objects.

My personal rule is use the stack unless
1) it's a particularly large object (1MB or more), or
2) I need the object to exist beyond local scope

Those two considerations pretty much decide it for me.

If I have a program which is written by other programmers, how to
detect whether the program use stack or heap.

Do you have the source? I guess that would make it obvious. If you
just have the binary I suppose you'd have to run it through a debugger
or disassembler. Look for calls to malloc() or similar for heap
allocations, and stack pointer adjustments for ... well, the stack. Of
course, unless you have an application designed for a very specific
platform, it will use both the heap and the stack. I'm not sure what
would cause you to doubt this.

--Jonathan

 

[moongeegee]

My personal rule is use the stack unless
1) it's a particularly large object (1MB or more), or
2) I need the object to exist beyond local scope

Those two considerations pretty much decide it for me.


Do you have the source? I guess that would make it obvious. If you
just have the binary I suppose you'd have to run it through a debugger
or disassembler. Look for calls to malloc() or similar for heap
allocations, and stack pointer adjustments for ... well, the stack. Of
course, unless you have an application designed for a very specific
platform, it will use both the heap and the stack. I'm not sure what
would cause you to doubt this.

--Jonathan

Hi Jonathan,

Thank you for the information.
Someone asked me whether C++ objects should store in stack or heap.
What is your answer if someone ask you the above question?
Appreciate your help.

 

[Jonathan Lee]

Thank you for the information.

You're welcome, moongeegee.

Someone asked me whether C++ objects should store in stack or heap.
What is your answer if someone ask you the above question?

The question is phrased a little strange. If you mean, "should an
object use stack or heap for _its_ storage", then I'd have to answer
"heap". An object that uses memory across calls to its member
functions must have persistent storage. That means heap.

But if you mean, "should an object itself be created on the heap or
stack", then I would prefer the stack. It saves an allocation from new
and it will be destructed for you when it leaves scope. Those are good
enough reasons for me (keeping in mind the exceptions I noted in the
previous post).

--Jonathan

 

[Fred Zwarts]

How to determine we should use either stack/static storage or heap for
C++ objects.
I know there are pro and con between stack/static storage and heap.
If I have a program which is written by other programmers, how to
detect whether the program
use stack or heap.
Thanks in advance.

I am not sure in how far this is a C++ question.
The C++ standard does not specify when objects are stored on the stack or on the heap.
This is a matter of implementations. Some implementations may not even use a stack.

Further the question itself is not clear at all.
For example, if a vector is declared as an automatic variable,
were is it stored? Part of it may be on the stack, but part of it may be on the heap.
Wrong questions will get wrong answers.

 

[James Kanze]

How to determine we should use either stack/static storage or
heap for C++ objects.

Use local variables (stack) when you can. Use dynamic
allocation (heap) when you have to. Some of the reasons which
might mean you have to:

-- The object has identity (can't be copied), and a lifetime
which doesn't correspond to that of local scope.

-- The object is polymorphic, and the exact type won't be known
until runtime.

-- The object is too big to fit on the stack. (This is a
purely technical issue, which means compromising with the
design.)

-- The object is too expensive to copy, and its value is needed
beyond local scope. (This is a purely optimization issue,
and shouldn't be invoked unless the profiler says you have a
problem. And there are often other solutions which are
better.)

I know there are pro and con between stack/static storage and
heap.

I don't know if you can speak of pros and cons. They server
different purposes.

If I have a program which is written by other programmers, how
to detect whether the program use stack or heap.

Why do you have to know? What difference does it make?

 

[James Kanze]

I am not sure in how far this is a C++ question.

It's very much a C++ question. The answer would be completely
different in Java. Or even C, for that matter.

The C++ standard does not specify when objects are stored on
the stack or on the heap. This is a matter of
implementations. Some implementations may not even use a
stack.

The standard does define differently lifetimes for variables.
Such as auto (commonly called stack), and dynamic (commonly
called heap). The standard may not use the word "stack", but
the semantics of auto variables requires one. In the same way,
it may not use the word "heap" (in the sense used here: the free
space arena), but the semantics of dynamic lifetime require one.

Further the question itself is not clear at all. For example,
if a vector is declared as an automatic variable, were is it
stored? Part of it may be on the stack, but part of it may be
on the heap.

If a vector is declared as an automatic variable, the vector
itself is on the stack. What it does behind the scenes is
irrelevant.

 

[Fred Zwarts]

If a vector is declared as an automatic variable, the vector
itself is on the stack. What it does behind the scenes is
irrelevant.

How do you know it is irrelevant?
There is not enough information in the question to tell whether it
is irrelevant or not.

 

[Fred Zwarts]

The standard does define differently lifetimes for variables.
Such as auto (commonly called stack), and dynamic (commonly
called heap). The standard may not use the word "stack", but
the semantics of auto variables requires one.

Could you be a bit more specific? Which part of the standard would
prohibit the use of heap storage for auto variables?

In the same way,
it may not use the word "heap" (in the sense used here: the free
space arena), but the semantics of dynamic lifetime require one.

Maybe there is a reason why the standard does not use the terms
stack and heap.

 

[KjellKod]

On embedded system that requires small memory footprint
It is not-uncommon that all objects are created on the stack.

In the case that you then need to get polymorphism,. (i.e.
viewing/using objects through an interface) you can pass the
objects by reference/pointer.

The downside with dynamic memory allocation (heap) according
to the advocates who work with systems described above is that
it is hard to do on such small systems (heap storage that is),.
including smarter use of memory with memory pools etc.

---> Of course a system such as described above helps if its very
design is very static in it's nature, then it doesn't matter
that much to make it on the stack.

I don't know if it IS that hard to work on the heap as well on small
embedded systems,. I've had the luxury to try :| I'm sure some
people reading this have tried it though!

Regards
Kjell

 

[James Kanze]

messagenews:76a6f752-8506-48f4-9ad9-2daaa7efe678@h11g2000yqb.googlegroups..com...

Could you be a bit more specific? Which part of the standard
would prohibit the use of heap storage for auto variables?

§3.7.2 Automatic storage duration
[...]
"The storage for these objects lasts until the block in which
they are created exits."

Maybe there is a reason why the standard does not use the terms
stack and heap.

Yes. The authors chose a different vocabulary, and used it
consistently. They could have just as easily called it "stack
duration" and "heap duration", and then used those terms
consistently. The terms the standard uses are probably
preferable in the context of the standard, since they seem to
relate to "duration" more than "stack" or "heap" do, but there's
no problem with using "stack" and "heap" in less formal
use---it's quite clear what is meant.

 

[Alf P. Steinbach]

* Fred Zwarts:

* "James Kanze":

Could you be a bit more specific? Which part of the standard would
prohibit the use of heap storage for auto variables?

It's not prohibited, and it would not contradict the requirement of auto
variables forming a stack, it would just be silly.

That is, it would then be a stack implemented in an extremely inefficient and
overcomplicated way by using dynamic storage behind the scenes.

It's possible that you're thinking of an overspecified notion of "stack". That
is, that your thinking of some particular low level way of implementing a stack.
In that case, check out your nearest reliable source of information on what a
"stack" is in computer science and programming.

Maybe there is a reason why the standard does not use the terms
stack and heap.

Regarding "stack", the standard does use that term about the auto variables,
e.g. "stack unwinding", "the stack".

Regarding "heap", that's a term with many incompatible meanings.

In the standard it's used exclusively in the data structure meaning.


Cheers & hth.,

- Alf

 

[Fred Zwarts]

messagenews:76a6f752-8506-48f4-9ad9-2daaa7efe678@h11g2000yqb.googlegroups..com...

Could you be a bit more specific? Which part of the standard
would prohibit the use of heap storage for auto variables?

§3.7.2 Automatic storage duration
[...]
"The storage for these objects lasts until the block in which
they are created exits."

This concerns only the life time, not the location.
Is there any reason why an auto variable created on the heap could not
be automatically deleted at the end of the block?

Yes. The authors chose a different vocabulary, and used it
consistently. They could have just as easily called it "stack
duration" and "heap duration", and then used those terms
consistently. The terms the standard uses are probably
preferable in the context of the standard, since they seem to
relate to "duration" more than "stack" or "heap" do, but there's
no problem with using "stack" and "heap" in less formal
use---it's quite clear what is meant.

I think there is another reason. The standard is only concerned
about the life time, not about the implementation.
Stack is more than life time, it is also a certain region of
memory, a certain ordered sequence of addresses, etc.
Since the standard is only concerned about the lifetime,
they formulated it in such a way that an implementation
is free to use the most efficient way for storage. In many cases
this means for auto variables stack and for dynamic variable heap,
but there might be cases were it is different.
So, speaking of stack and heap, without saying whether you refer
only to the lifetime, or also to the other aspects of stack and heap,
makes it less clear what is meant.

 

[Fred Zwarts]

* Fred Zwarts:

It's not prohibited, and it would not contradict the requirement of auto
variables forming a stack, it would just be silly.

That is, it would then be a stack implemented in an extremely inefficient and
overcomplicated way by using dynamic storage behind the scenes.

It's possible that you're thinking of an overspecified notion of "stack". That
is, that your thinking of some particular low level way of implementing a stack.
In that case, check out your nearest reliable source of information on what a
"stack" is in computer science and programming.

Exactly. The word "stack" has different meanings in computer science.
Using such words where the standard has words with a clear meaning
(auto or dynamic), opens the possibility for misunderstanding.
So my question was meant for the OP, to make clear that his question
is open for different interpretations.