Re: Stack vs. Heap
From: Peter van Merkerk (merkerk_at_deadspam.com)
Date: 10/09/03
- Next message: Mike Wahler: "Re: BREAKING NEWS: WMD found"
- Previous message: Moonlit: "Re: where are my objects???"
- In reply to: Kevin Grigorenko: "Stack vs. Heap"
- Next in thread: tom_usenet: "Re: Stack vs. Heap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 9 Oct 2003 10:54:47 +0200
> 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.
-- Peter van Merkerk peter.van.merkerk(at)dse.nl
- Next message: Mike Wahler: "Re: BREAKING NEWS: WMD found"
- Previous message: Moonlit: "Re: where are my objects???"
- In reply to: Kevin Grigorenko: "Stack vs. Heap"
- Next in thread: tom_usenet: "Re: Stack vs. Heap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
