Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > where? heap or stack?

Reply
Thread Tools

where? heap or stack?

 
 
Jonas Rundberg
Guest
Posts: n/a
 
      05-05-2004
Hi
I just started with c++ and I'm a little bit confused where stuff
go...
Assume we have a class:

class test {
private:
int arr[100];
};

That is, I assume that 'arr' is allocated on the stack, since I don't
use new.
But where is this array allocated if I allocate a test object in the
heap?
I.e.
test t = new test;
The object will reside in the heap so therefore the 'arr' will be in
the heap too?

Are there any pro/cons to heap/stack allocate member variables (of non
trivial type)?

Thanks
Jonas
 
Reply With Quote
 
 
 
 
Jeff Schwab
Guest
Posts: n/a
 
      05-05-2004
Jonas Rundberg wrote:
> Hi
> I just started with c++ and I'm a little bit confused where stuff
> go...
> Assume we have a class:
>
> class test {
> private:
> int arr[100];
> };
>
> That is, I assume that 'arr' is allocated on the stack, since I don't
> use new.


It hasn't been allocated at all. So far, you've defined a new type, but
allocated nothing.

> But where is this array allocated if I allocate a test object in the
> heap?
> I.e.
> test t = new test;
> The object will reside in the heap so therefore the 'arr' will be in
> the heap too?


Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
refer to standard data structures, not to regions of memory.

> Are there any pro/cons to heap/stack allocate member variables (of non
> trivial type)?


http://groups.google.com/groups?hl=e...er&btnG=Search

Basically, prefer the stack when you can, since it tends to be faster
and less error-prone. For very large objects, objects that must
out-live the scope of their definitions, and collections of unknown
size, use the heap.


>
> Thanks
> Jonas

 
Reply With Quote
 
 
 
 
Jeff Schwab
Guest
Posts: n/a
 
      05-05-2004
Jeff Schwab wrote:

> For very large objects, objects that must
> out-live the scope of their definitions, and collections of unknown
> size, use the heap.


Unknown at compile time, that is.
 
Reply With Quote
 
Thomas Matthews
Guest
Posts: n/a
 
      05-05-2004
Jonas Rundberg wrote:
> Hi
> I just started with c++ and I'm a little bit confused where stuff
> go...
> Assume we have a class:
>
> class test {
> private:
> int arr[100];
> };
>
> That is, I assume that 'arr' is allocated on the stack, since I don't
> use new.
> But where is this array allocated if I allocate a test object in the
> heap?
> I.e.
> test t = new test;
> The object will reside in the heap so therefore the 'arr' will be in
> the heap too?
>
> Are there any pro/cons to heap/stack allocate member variables (of non
> trivial type)?
>
> Thanks
> Jonas


First off, according to the ANSI/ISO standard, there is no
requirement for a heap or a stack.

But I will refer to the "heap" as _dynamic_memory_. Dynamic
memory is memory that is allocated by a program during
run-time and the program controls the life-span of these objects.
This area of memory is accessed by the new operator and *alloc
functions.

Lifetime of variables: When the program creates it,
until the program destroys it.

Example:
test * pointer;
//...
pointer = new test;


There is also another region of memory where automatic,
and static variables are placed. Objects are allocated
in this memory by the compiler before the "main" function
is executed. Global variables, variables declared in
static with file scope, variables declared as static in
functions or blocks are allocated from this memory area.

Lifetime of variables: Program start to program end.

Example:
test global_test_variable;
void Example1(void)
{
static test static_function_variable;
return;
}


The next common area of memory is where local function
and block variables are stored. These variables
are allocated before the block or function is executed
and destroyed upon exit of the function or block.

Lifetime of variables: Start of function or block
until the end of the function
or block.

Example:
void Example2(void)
{
test a_local_variable;

for (unsigned int i = 0; i < 10; ++i)
{
test a_block_variable;
a_block_variable.a[i] = i;
}
return;
}


In your example, the identifier, "arr", names a
field, or member, of the class "test". This member
will always be a part of the class. All variables
of type "test" will have the "arr" member; regardless
of where the variable or instance resides.

There are two common usages for allocation from the
"heap": huge variables and variables whose size or
need are determined at run-time. Many compilers have
a fixed sized area for the automatic and "stack"
memory areas. They usually limit the size of the
"heap" to the amount of memory left in the platform.
Thus the heap is usually larger than the other two
memory areas.

Often times, objects need to be created during run-time.
The quantity or size is determined by factors outside
of your program. Examples: databases, messages,
image processing, audio processing and data logging.
With audio processing, one doesn't know the quantity
of data until runtime. With message processing, the
program doesn't know which message it will receive
and when.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-05-2004
On Wed, 05 May 2004 06:25:18 -0400, Jeff Schwab <(E-Mail Removed)>
wrote:


>Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
>refer to standard data structures, not to regions of memory.
>


Interesting this issue should just now come up, as I was wondering myself
about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
Throughout the book, they use the word "heap" synonymously with "free
store". IOW, instead of saying "allocated dynamically" or even "allocated
on/from the free store", they consistently say "from the heap", use the
term "heap memory", and even name a utility class for monitoring use of
new/delete "TraceHeap".

Now I'm used to seeing this wording being picked on, but hasn't it in fact
become effectively idiomatic to say "allocated on the heap" when you simply
mean dynamically? Sort of like the word "momentarily" has now,
unfortunately, become effectively synonymous with "in a moment"? In
reality, how often is the use of the word "heap" /really/ going to be
ambiguous when it pops up in discussions like this? I'm not happy about it,
but I'd vote to bite the bullet and just let people say "heap" unmolested
unless it really isn't clear what they're talking about...
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
Jeff Schwab
Guest
Posts: n/a
 
      05-05-2004
Leor Zolman wrote:
> On Wed, 05 May 2004 06:25:18 -0400, Jeff Schwab <(E-Mail Removed)>
> wrote:
>
>
>
>>Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
>>refer to standard data structures, not to regions of memory.
>>

>
>
> Interesting this issue should just now come up, as I was wondering myself
> about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
> Throughout the book, they use the word "heap" synonymously with "free
> store". IOW, instead of saying "allocated dynamically" or even "allocated
> on/from the free store", they consistently say "from the heap", use the
> term "heap memory", and even name a utility class for monitoring use of
> new/delete "TraceHeap".
>
> Now I'm used to seeing this wording being picked on, but hasn't it in fact
> become effectively idiomatic to say "allocated on the heap" when you simply
> mean dynamically? Sort of like the word "momentarily" has now,
> unfortunately, become effectively synonymous with "in a moment"? In
> reality, how often is the use of the word "heap" /really/ going to be
> ambiguous when it pops up in discussions like this? I'm not happy about it,
> but I'd vote to bite the bullet and just let people say "heap" unmolested
> unless it really isn't clear what they're talking about...


You're absolutely right. The FAQ for this group even refers to the
stack & the heap in the idiomatic way. Unfortunately, when one uses
these terms in a news group posting, someone likely will get very huffy
and say something pedantic unless you beat them to the punch. I try to
do nip such complaints in the bud in a more humane way than some folks
might.

Of course, in "real world" conversations, development is usually being
done for well-known platforms, so I can point to documentation that
explains the free store really is a heap, and that function-scoped
variables really are on a stack.
 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-05-2004
On Wed, 05 May 2004 10:13:03 -0400, Jeff Schwab <(E-Mail Removed)>
wrote:

>Leor Zolman wrote:
>> On Wed, 05 May 2004 06:25:18 -0400, Jeff Schwab <(E-Mail Removed)>
>> wrote:
>>
>>
>>
>>>Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
>>>refer to standard data structures, not to regions of memory.
>>>

>>
>>
>> Interesting this issue should just now come up, as I was wondering myself
>> about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
>> Throughout the book, they use the word "heap" synonymously with "free
>> store". IOW, instead of saying "allocated dynamically" or even "allocated
>> on/from the free store", they consistently say "from the heap", use the
>> term "heap memory", and even name a utility class for monitoring use of
>> new/delete "TraceHeap".
>>
>> Now I'm used to seeing this wording being picked on, but hasn't it in fact
>> become effectively idiomatic to say "allocated on the heap" when you simply
>> mean dynamically? Sort of like the word "momentarily" has now,
>> unfortunately, become effectively synonymous with "in a moment"? In
>> reality, how often is the use of the word "heap" /really/ going to be
>> ambiguous when it pops up in discussions like this? I'm not happy about it,
>> but I'd vote to bite the bullet and just let people say "heap" unmolested
>> unless it really isn't clear what they're talking about...

>
>You're absolutely right. The FAQ for this group even refers to the
>stack & the heap in the idiomatic way. Unfortunately, when one uses
>these terms in a news group posting, someone likely will get very huffy
>and say something pedantic unless you beat them to the punch. I try to
>do nip such complaints in the bud in a more humane way than some folks
>might.
>
>Of course, in "real world" conversations, development is usually being
>done for well-known platforms, so I can point to documentation that
>explains the free store really is a heap, and that function-scoped
>variables really are on a stack.


One way to deal with this is just to use the "proper" terminology in
responses. Looking back over some of my replies, I've tended to just stick
with the OP's terminology (if they say "heap", I say "heap" too) most of
the time, while occasionally switching. Now that I'm focused on the issue
more, it may work well to note the change-over, e.g:

OP: blah blah blah on the heap blah blah blah
me: blah blah blah on the free store (heap) blah blah blah ...
and then just use free store, or "dynamic", from then on.

There may be no perfect solution, but there are really enough bigger fish
to fry (and I'm addressing the entire group with this, not just you, Jeff,
and that was also the case before) that I suggest we all just let this
little one go if we catch it
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
Claudio Puviani
Guest
Posts: n/a
 
      05-05-2004
"Leor Zolman" <(E-Mail Removed)> wrote
Jeff Schwab <(E-Mail Removed)> wrote:
> >
> >Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
> >refer to standard data structures, not to regions of memory.
> >

>
> Interesting this issue should just now come up, as I was wondering myself
> about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
> Throughout the book, they use the word "heap" synonymously with "free
> store". IOW, instead of saying "allocated dynamically" or even "allocated
> on/from the free store", they consistently say "from the heap", use the
> term "heap memory", and even name a utility class for monitoring use of
> new/delete "TraceHeap".


Herb Sutter, in GotW #9 (and subsequently in "Exceptional C++"), makes a
distinction between "heap" and "free store" (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).


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.


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.


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!


 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      05-05-2004
> 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.



I always understood 'new' as something that calls a constructor apart
from (m)allocating memory. And this snippet says that free store objects
are created using 'new' , but need not be initialised immediately ? (
which constructor is supposed to take care ?)

Maybe I'm totally missing out on something


Claudio Puviani wrote:
> "Leor Zolman" <(E-Mail Removed)> wrote
> Jeff Schwab <(E-Mail Removed)> wrote:
>
>>>Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
>>>refer to standard data structures, not to regions of memory.
>>>

>>
>>Interesting this issue should just now come up, as I was wondering myself
>>about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
>>Throughout the book, they use the word "heap" synonymously with "free
>>store". IOW, instead of saying "allocated dynamically" or even "allocated
>>on/from the free store", they consistently say "from the heap", use the
>>term "heap memory", and even name a utility class for monitoring use of
>>new/delete "TraceHeap".

>
>
> Herb Sutter, in GotW #9 (and subsequently in "Exceptional C++"), makes a
> distinction between "heap" and "free store" (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).
>
>
> 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.
>
>
> 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.
>
>
> 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!
>
>


 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      05-05-2004
On Wed, 05 May 2004 15:54:19 GMT, "Claudio Puviani" <(E-Mail Removed)>
wrote:

>"Leor Zolman" <(E-Mail Removed)> wrote
>Jeff Schwab <(E-Mail Removed)> wrote:
>> >
>> >Yes. Careful about calling it "heap," though; "stack" and "heap" in C++
>> >refer to standard data structures, not to regions of memory.
>> >

>>
>> Interesting this issue should just now come up, as I was wondering myself
>> about it while reading through Eckel/Allison's _Thinking in C++ Volume II_.
>> Throughout the book, they use the word "heap" synonymously with "free
>> store". IOW, instead of saying "allocated dynamically" or even "allocated
>> on/from the free store", they consistently say "from the heap", use the
>> term "heap memory", and even name a utility class for monitoring use of
>> new/delete "TraceHeap".

>
>Herb Sutter, in GotW #9 (and subsequently in "Exceptional C++"), makes a
>distinction between "heap" and "free store" (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.
>


[Herb's summary snipped]

>
>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!
>


All of which I have no problem with; the point I was trying to make is that
this distinction is usually /beside the point/ in the context of many
(most?) questions that arise concerning dynamic memory.

A continuous challenge in newsgroup postings (esp. responses), and one I
always struggle with personally, is to know how much detail to go into.
Often you just can't tell without the proverbial crystal ball; thus, my
instinct is to err on the side of providing /less/ detail, and not to open
Pandora's box if it isn't clear the OP has requested it opened.

Not to beat a dead horse (or further pummel Jeff), but take a look at the
subject of the OP's question in this thread, and at the body of that
question. Do you really think this particular OP really needed to know that
the "heap" was something other than the free store (maybe)? I don't think
so. He may not even have been aware that there was any such thing as
"malloc" and "free"; certainly, someone learning C++ the modern way would
have no need to know about those functions (yet). This is precisely where a
little bit of restraint would, IMHO, go a long way.
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How much heap can I reserve for JVM? Error when allocation very much heap Raymond Schanks Java 0 04-11-2010 04:25 PM
stl heap question: restoring heap validinty after changing 1 element viki C++ 6 06-28-2008 10:12 AM
Heap dump file size vs heap size Michal Slocinski Java 1 03-25-2008 12:54 PM
Windows Desktop Heap Tweak Guide Posted! Silverstrand Front Page News 0 07-20-2005 10:46 PM
aspnet_wp.exe - relation heap mem to virtual memory Rob ASP .Net 0 08-01-2003 10:09 AM



Advertisments