Re: where? heap or stack?
From: E. Robert Tisdale (E.Robert.Tisdale_at_jpl.nasa.gov)
Date: 05/06/04
- Next message: Default User: "Re: Visual C++ 7.1 INTERNAL COMPILER ERROR"
- Previous message: Claudio Puviani: "Re: where? heap or stack?"
- In reply to: Claudio Puviani: "Re: where? heap or stack?"
- Next in thread: Claudio Puviani: "Re: where? heap or stack?"
- Reply: Claudio Puviani: "Re: where? heap or stack?"
- Reply: Michiel Salters: "Re: where? heap or stack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 05 May 2004 15:05:21 -0700
Claudio Puviani wrote:
>
> Herb Sutter, in GotW #9 (and subsequently in "Exceptional C++"),
> makes a distinction between "heap" and "free store"
Unfortunately, Herb is *wrong*.
> (hopefully, Herb won't sue me for copying and pasting):
>
>
> The following summarizes a C++ program's major distinct memory areas.
> Note that some of the names (e.g., "heap") do not appear as such in
> the draft.
>
>
> Memory Area Characteristics and Object Lifetimes
> -------------- ------------------------------------------------
>
> Const Data The const data area stores string literals and
> other data whose values are known at compile
> time. No objects of class type can exist in
> this area. All data in this area is available
> during the entire lifetime of the program.
>
> Further, all of this data is read-only, and the
> results of trying to modify it are undefined.
> This is in part because even the underlying
> storage format is subject to arbitrary
> optimization by the implementation. For
> example, a particular compiler may store string
> literals in overlapping objects if it wants to.
>
>
> Stack The stack stores automatic variables. Typically
> allocation is much faster than for dynamic
> storage (heap or free store) because a memory
> allocation involves only pointer increment
> rather than more complex management. Objects
> are constructed immediately after memory is
> allocated and destroyed immediately before
> memory is deallocated, so there is no
> opportunity for programmers to directly
> manipulate allocated but uninitialized stack
> space (barring willful tampering using explicit
> dtors and placement new).
C++ does *not* require a program stack to implement free storage
but free storage is always implemented on the program stack
in all viable implementations so a reference to the stack
in the context of a C++ program is *always* a reference to
the underlying implementation and *not* the language itself.
>
>
> Free Store The free store is one of the two dynamic memory
> areas, allocated/freed by new/delete. Object
> lifetime can be less than the time the storage
> is allocated; that is, free store objects can
> have memory allocated without being immediately
> initialized, and can be destroyed without the
> memory being immediately deallocated. During
> the period when the storage is allocated but
> outside the object's lifetime, the storage may
> be accessed and manipulated through a void* but
> none of the proto-object's nonstatic members or
> member functions may be accessed, have their
> addresses taken, or be otherwise manipulated.
>
>
> Heap The heap is the other dynamic memory area,
> allocated/freed by malloc/free and their
> variants. Note that while the default global
> new and delete might be implemented in terms of
> malloc and free by a particular compiler, the
> heap is not the same as free store and memory
> allocated in one area cannot be safely
> deallocated in the other. Memory allocated from
> the heap can be used for objects of class type
> by placement-new construction and explicit
> destruction. If so used, the notes about free
> store object lifetime apply similarly here.
If there is a data structure called "heap",
it is feature of your implementation and *not* standard C or C++.
There is *no* requirement that new/delete malloc/free
manage different data structures.
In a typical implementation, new and delete are implemented
by calling malloc and free respectively
and they manage the same data structure.
Free storage is exactly what is meant by the free storage.
It is [virtual] memory which has not yet been [re]allocated
for use by your program. In the typical implementation,
it is free memory below the bottom of the text (code) segment
and above the top of the program (process) stack.
Generally, the stack grows up into free storage.
In the typical implementation, the remainder of free storage
is managed by a *free list*. The term heap was coined
by IBM programmers as a whimsical name
for their implementation of a free list.
It is a *pun* which contrasts it with the term stack.
>
>
> Global/Static Global or static variables and objects have
> their storage allocated at program startup, but
> may not be initialized until after the program
> has begun executing. For instance, a static
> variable in a function is initialized only the
> first time program execution passes through its
> definition. The order of initialization of
> global variables across translation units is not
> defined, and special care is needed to manage
> dependencies between global objects (including
> class statics). As always, uninitialized proto-
> objects' storage may be accessed and manipulated
> through a void* but no nonstatic members or
> member functions may be used or referenced
> outside the object's actual lifetime.
The location of constant or variable global or static objects
is left up to the implementation. Constants may be and often are
embedded in the text (code) segment and small integral constants
may be loaded immediately out of the instruction stream.
Variables may be placed in a special data segment right after
the text segment. at the bottom of the program stack
or even allocated from free storage.
>
>
> Note about Heap vs. Free Store: We distinguish between "heap" and
> "free store" because the draft deliberately leaves unspecified the
> question of whether these two areas are related. For example,
> when memory is deallocated via operator delete, 18.4.1.1 states:
>
> It is unspecified under what conditions part or all of such
> reclaimed storage is allocated by a subsequent call to operator new
> or any of calloc, malloc, or realloc, declared in <cstdlib>.
>
> Similarly, it is unspecified whether new/delete is implemented in
> terms of malloc/free or vice versa in a given implementation.
> Effectively, the two areas behave differently and are accessed
> differently -- so be sure to use them differently!
>
>
- Next message: Default User: "Re: Visual C++ 7.1 INTERNAL COMPILER ERROR"
- Previous message: Claudio Puviani: "Re: where? heap or stack?"
- In reply to: Claudio Puviani: "Re: where? heap or stack?"
- Next in thread: Claudio Puviani: "Re: where? heap or stack?"
- Reply: Claudio Puviani: "Re: where? heap or stack?"
- Reply: Michiel Salters: "Re: where? heap or stack?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
