Stack vs. Heap

[Kevin Grigorenko]

Hello,

I couldn't find an obvious answer to this in the FAQ. My basic question,
is: Is there any difference in allocating on the heap versus the stack? If
heap or stack implementation is not part of the standard, then just
disregard this question. Here's some questions I'm confused about, and if
you can add anything else, please do so!

Is the stack limited for each program?

On the other hand, is the heap basically limitless (except of course limited
to the size of memory or page files)?

If I've got something on the heap, as I understand it, another program can
update any of my allocated storage without me knowing? Can this happen on
the stack?

Is there any performance difference in using variables on the stack versus
on the heap?

Are global and static variables on the stack?

The reason I ask is I'm starting to get into C#, and it makes a big deal
about allocating a lot of stuff on a garbage collected heap. I wouldn't
want to start asking off-topic questions, so I'll just ask this: would a
concept like this follow from the fact that heap storage is better to use
for some reason rather than storage on the stack?

I appreciate it!
Kevin Grigorenko

 

[E. Robert Tisdale]

I couldn't find an obvious answer to this in the FAQ. My basic question,
is: Is there any difference in allocating on the heap versus the stack?
If heap or stack implementation is not part of the standard, then just
disregard this question. Here's some questions I'm confused about, and if
you can add anything else, please do so!

Is the stack limited for each program?

On the other hand, is the heap basically limitless (except of course limited
to the size of memory or page files)?

If I've got something on the heap, as I understand it, another program can
update any of my allocated storage without me knowing? Can this happen on
the stack?

Is there any performance difference in using variables on the stack versus
on the heap?

Are global and static variables on the stack?

The reason I ask is I'm starting to get into C#, and it makes a big deal
about allocating a lot of stuff on a garbage collected heap. I wouldn't
want to start asking off-topic questions, so I'll just ask this: would a
concept like this follow from the fact that heap storage is better to use
for some reason rather than storage on the stack?

It depends upon your compiler.
Please tell us which compiler you are using
so that we can redirect to to the appropriate newsgroup.

 

[Kevin Grigorenko]

It depends upon your compiler.
Please tell us which compiler you are using
so that we can redirect to to the appropriate newsgroup.

All of those questions are non-standard? Ok, I have no doubts, you guys are
the experts. Let's say the compiler I'm using is VC++6. Also, I was
looking for a C# newsgroup, so if you could also direct me to where I can
post questions regarding that, that would be great. I couldn't find
anything to the effect of comp.lang.csharp.

Is the concept of stack and heap completely independent of the standard?

Thanks again!
Kevin Grigorenko

 

[Josephine Schafer]

Also, I was

looking for a C# newsgroup, so if you could also direct me to where I can
post questions regarding that, that would be great. I couldn't find
anything to the effect of comp.lang.csharp.

On Microsoft's news server (msnews.microsoft.com) -
microsoft.public.dotnet.languages.csharp.

 

[Mike Wahler]

and happen

All of those questions are non-standard?

While often implemented with 'stacks' and 'heaps',
the C++ standard makes no requirements (or prohibitions)
that they be used for memory management in a C++
program. Storage is only classified as 'automatic'
(local variables), 'static' (file scope variables,
or local variables or class members specifically
made static with the 'static' keyword), and
'allocated', a.k.a. 'dynamic' (objects created
with 'new', 'new[]' , 'calloc()', 'malloc()' or
'realloc()'

How these classes of storage are actually implemented
is, well, implementation defined.

Ok, I have no doubts, you guys are
the experts.

The skill level of people here varies widely, from
complete novice to true 'gurus', some of whom are
members of the ISO committee which standardized
the C++ language. Even 'god' himself , Bjarne
Stroustrup, has been known to drop in from time to
time. Spend some time here, and I think you'll
quickly get a feel for "who's who."

Let's say the compiler I'm using is VC++6.

Here, it doesn't really matter which implementation
(aka 'compiler') you use. C++ is a platform independent
language. That's what the 'standard' is all about.

Also, I was
looking for a C# newsgroup, so if you could also direct me to where I can
post questions regarding that, that would be great.

I'm pretty sure there are links to the C# (and other
MS stuff) newsgroups at www.msdn.microsoft.com

www.usenet.org and www.groups.google.com also have
newsgroup directories.

I couldn't find
anything to the effect of comp.lang.csharp.

I think it's called
microsoft.public.dotnet.languages.csharp

but you can check the MSDN site to be sure.

Is the concept of stack and heap completely independent of the standard?

Yes. object storage in standard C++ is only
classified as 'automatic', 'static', and
'allocated'.

Much good information about standard C++ here:
http://www.parashift.com/c++-faq-lite/


Info about this newsgroup:
http://www.parashift.com/c++-faq-lite/


Information about a learning newsgroup for C and C++
(alt.comp.lang.learn.c-c++):
http://www.contrib.andrew.cmu.edu/~ajo/faqs/acllc-c++.html
The "official" link is currently "out of order",
this is a "mirror" of it (Thanks Arthur!)

HTH,
-Mike

 

[Peter van Merkerk]

I couldn't find an obvious answer to this in the FAQ. My basic
question,

is: Is there any difference in allocating on the heap versus the stack? If
heap or stack implementation is not part of the standard, then just
disregard this question. Here's some questions I'm confused about, and if
you can add anything else, please do so!

Is the stack limited for each program?

The C++ standard doesn't say anything about stack or its size (other
than template class std::stack which is a different topic). But
practically speaking the stack size is limited. How big the stack size
is is depends on platform linkers settings...etc, in other words there
is no standard answer to your question.

On the other hand, is the heap basically limitless (except of course limited
to the size of memory or page files)?

Typically the stack is smaller than the available free store (=heap).
Again the C++ standard doesn't say anything about this, so the answer
depends on what platform you are using.

If I've got something on the heap, as I understand it, another program can
update any of my allocated storage without me knowing?

Since the C++ standard says nothing about running multiple processes on
the same system, this is an OS/platform issue not an C++ issue. OSes
like Linux and the 32-bit Windows versions normally do not allow one
program to write in the memory space of another program (though often
the OS does provide means to get around this barrier for example to
allow debuggers to change variables). Other OSes provide no protection
at all.

Can this happen on the stack?

Since stacks typically reside in the same memory space as the heap the
same rules apply. If the OS/platform allows other programs to write to
the memory space of your program they can potentially damage the stack
as well. If you have a multithreaded program, each thread has its own
stack but typically share one heap.

Is there any performance difference in using variables on the stack versus
on the heap?

Stack variable tend to be faster because most if not all the work to
allocate space on the stack can be done during compile time. For heap
allocation something always needs to be done during runtime.

Are global and static variables on the stack?
No.

The reason I ask is I'm starting to get into C#, and it makes a big deal
about allocating a lot of stuff on a garbage collected heap. I wouldn't
want to start asking off-topic questions, so I'll just ask this: would a
concept like this follow from the fact that heap storage is better to use
for some reason rather than storage on the stack?

No, the reason why C# more heavilly relies on heap is because it is
fundamentally different programming language than C++. The trade offs
are different and consequently things that make sense with C# (or Java
for that matter) do not necessarilly make sense in C++.

In C++ use stack objects where you can, use heap objects when you have
to. Besides efficiency of stack objects another (often even more
important) plus of stack objects is the automatic cleanup when they run
out of scope. Because C++ has no garbage collected heap, manually
creating and destroying objects on the heap is not only a pain, but also
difficult to get right i.c.w. exceptions.

 

[David B. Held]

[...]
Is there any difference in allocating on the heap versus
the stack?

Yes. It's one of the most fundamental storage issues in
programming. In C++, stack-allocated variables have
"automatic" storage, which means that their storage is
allocated automatically, and they are destroyed
automatically when they go out of scope. Heap-allocated
data is allocated explicitly and destroyed explicitly, which
allows you to control its lifetime.

[...]
Is the stack limited for each program?

That's implementation-dependent. Some systems have a
fixed-size stack, and others will grow the stack for you up
to a limit. All systems will experience a stack overflow if
you call a recursive function with no terminating condition.
In that technical sense, the answer is "yes". ;>

C++ does not specify any limit on the heap size. However,
your heap will be limited by the address space of your
hardware, at the least.

If it can get a reference into your storage, yes. Whether that
is allowed depends on your operating system, not your
programming language.

Implementation-defined.

Heap allocation is almost always more expensive than
stack allocation, and often by a significant margin.

They are typically allocated their own (non-stack) storage.

Garbage collection is a whole different ball of wax. The
allocation/collection times may be totally different for a
collected system than an explicitly allocated system. So
getting answers about C++ won't necessarily tell you about
C#. Whether you pay a performance penalty depends on
the nature of your application. One can always produce
pathological test cases for any allocation scheme. It
also depends on your requirements.

[...]
would a concept like this follow from the fact that heap
storage is better to use for some reason rather than
storage on the stack?

Generally, the so-called "4GL" languages tend to prefer
heap allocation because it makes dealing with references
simpler. If everything lives on the heap, then you can't end
up with a dangling reference. It may also simply the design
and implementation of the language in other ways. It is
certainly not because heap allocation with collection is
always a better method.

[...]
All of those questions are non-standard?

Not at all. Many of them are relevant to C++.

Ok, I have no doubts, you guys are the experts.

You can't assume that anyone who posts here is an expert
(me included!).

Let's say the compiler I'm using is VC++6.

Don't forget to always start your programs with "void main()". ;>

Also, I was looking for a C# newsgroup, so if you could
also direct me to where I can post questions regarding
that, that would be great. I couldn't find anything to the
effect of comp.lang.csharp.

It's not exactly as popular as other older languages. Whether
that is a good or bad thing is up to you to decide.

Is the concept of stack and heap completely independent
of the standard?

Many languages utilize the concept of a stack and program
heap (most stack-based languages, for instance). But if you
are asking if the C++ standard talks about them, it most
certainly does. Otherwise, it would have a peculiar time
explaining operator new and delete.

Dave

 

[Mike Wahler]

Many languages utilize the concept of a stack and program
heap (most stack-based languages, for instance). But if you
are asking if the C++ standard talks about them, it most
certainly does.

Citations please.

-Mike

 

[David B. Held]

Citations please.

Well, 12.5, for instance. The standard calls it the "free store",
but I would be interested to see your argument for why that
doesn't mean "program heap".

Then there's 15.2/3, which talks about "stack unwinding". It's
pretty hard to unwind a stack if you don't have a stack.

Dave

 

[tom_usenet]

Hello,

I couldn't find an obvious answer to this in the FAQ. My basic question,
is: Is there any difference in allocating on the heap versus the stack?

Yes, lots.

If

heap or stack implementation is not part of the standard, then just
disregard this question.

They aren't part of the standard, but the related concepts of
"automatic storage" and "dynamic storage" (often implemented as a
stack and heap respectively) are.

Is the stack limited for each program?

Yes, usually, in a platform dependent manner.

On the other hand, is the heap basically limitless (except of course limited
to the size of memory or page files)?

Yes, usually, but this is platform dependent.

If I've got something on the heap, as I understand it, another program can
update any of my allocated storage without me knowing? Can this happen on
the stack?

OS dependent. Modern OSes usually have protected memory spaces - each
process can only access its own memory.

Is there any performance difference in using variables on the stack versus
on the heap?

A big one. Automatic storage is usually *much* faster than dynamic
storage.

Are global and static variables on the stack?

No. They are in "static storage", which may be allocated at program or
module startup.

The reason I ask is I'm starting to get into C#, and it makes a big deal
about allocating a lot of stuff on a garbage collected heap. I wouldn't
want to start asking off-topic questions, so I'll just ask this: would a
concept like this follow from the fact that heap storage is better to use
for some reason rather than storage on the stack?

With dynamic storage you can control the lifetime of the storage,
whereas with automatic storage the storage is lost when the variable
goes out of scope.

However, the fact that automatic storage can be used for class objects
as well as int, double, etc. is one of C++'s strengths. Because
automatic storage is so much faster, this gives C++ an overwhelming
performance advantage in some situations over languages (like Java and
C#) that only allow allocation of class objects in dynamic storage. In
addition, use of the stack allows C++ to provide a superior construct
to finally - RAII through destructors.

To summarize, use automatic storage whenever you can and dynamic
storage only when you must.

Tom

 

[Gavin Deane]

Is the concept of stack and heap completely independent of the standard?

The standard defines static, dynamic and automatic storage duration,
which determine the life time of objects in your program. How those
storage durations are implemented (stack, heap, some other system),
whether there is a maximum amount of memory available, and whether
other programs can interfere with memory you have used are all details
specific to your implementation and operating system.

GJD

 

[osmium]

Formally, yes. But if someone from Mars were to implement a compiler they
would likely invent the stack shortly after they started to write the code
for the "auto" type. But they might use a different name for it.

 

[=?iso-8859-1?Q?Juli=E1n?= Albo]

osmium escribió:

Formally, yes. But if someone from Mars were to implement a compiler they
would likely invent the stack shortly after they started to write the code
for the "auto" type. But they might use a different name for it.

I have read on www.perl.org that Parrot will use a linked list of
garbage collected structures.

Regards.

 

[Gavin Deane]

Well, 12.5, for instance. The standard calls it the "free store",
but I would be interested to see your argument for why that
doesn't mean "program heap".

Then there's 15.2/3, which talks about "stack unwinding". It's
pretty hard to unwind a stack if you don't have a stack.

Though perhaps not impossible, since "stack unwinding" is defined
without "stack" being defined.

GJD

 

[WW]

Though perhaps not impossible, since "stack unwinding" is defined
without "stack" being defined.

The following standards contain provisions which, through reference in this
text, constitute provisions of this International Standard...

- ISO/IEC 2382 (all parts), Information technology - Vocabulary

So it seems stack does not need to be defined in the C++ standard.