heap vs stack

[Why Tea]

With respect to the lifetime of an application, my understanding
is that all data on the stack will be released, but data allocated
on the heap will remain unless manually freed. I believe this is
the same between C and C++.

But I read about this statement about C++ object "The lifetime
of a heap allocated object is only limited by the lifetime of the
application." at http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Companion/glossary/heap.html
Does it imply there is some kind of garbage collection, or is this
how C++ works?

This is what Stroustroup says in his book:
An object created by n e w exists until it is explicitly destroyed
by delete . Then, the space it occupied can be reused by new.
A C++ implementation does not guarantee the presence of a
‘‘garbage collector’’ that looks out for unreferenced objects and
makes them available to n e w for reuse. Consequently, I will
assume that objects created by n e w are manually freed using
delete . If a garbage collector is present, the deletes can be
omitted in most cases.

I would like to hear some expert comments on this.

/Why Tea

 

[Seebs]

With respect to the lifetime of an application, my understanding
is that all data on the stack will be released, but data allocated
on the heap will remain unless manually freed. I believe this is
the same between C and C++.

You are confused -- the concepts don't necessarily have any meaning.
Not every implementation works like that at all.

In most modern systems, ALL memory reserved by an application is
released when it closes. With some strange exceptions. But in
general, "allocated" memory is associated with the application, and
the OS will release all the resources as part of destroying
the application.

But the most important thing, from a learning the language perspective,
is to realize the following:

THERE IS NOT NECESSARILY ANY SUCH THING AS "THE" HEAP.

Or "the" stack.

There exist systems on which any resources allocated to the application
MUST be manually freed, or on which some kinds must and others don't
need to be, and so on. If you want to know what happens when your
application terminates, read the operating system documentation; the
C and C++ language specs do not really address these issues.

-s

 

[Malcolm McLean]

But I read about this statement about C++ object "The lifetime
of a heap allocated object is only limited by the lifetime of the
application." athttp://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/...
Does it imply there is some kind of garbage collection, or is this
how C++ works?

There's no garbage collection in C++ or C, though some compilers
(notably lcc-win) provide it as a non-standard extension.

In C it is necessary to call malloc() to allocate memory and free() to
release it. On almost every platform, terminating the application will
also free all memory allocated by it (in a sense this is garbage
collection). There are just a few platforms where unfreed memory
remains locked up until someone reboots the computer.

In C++ new and delete are basically malloc() / free(), with bells and
whistles to allow objects to be created and destroyed. However in
modern C++ they fade away, because the use of standard template
library containers makes them unnecessary. The containers call delete
internally when they go out of scope and their destructor is called.
This gives the illusion of garbage collection in C++.

True garbage collection, which occurs in Java, is usally implemented
by keeping a list of allocated blocks. The garbage collector then
sweeps the variable space. If no pointers remain to a block, it is
orphaned and marked for deletion. This slows the program down
unpredictably, which is why C doesn't implement it.

 

[Shao Miller]

I would like to hear some expert comments on this.

What about just "plain" comments?

In the C Standard sometimes called C99, I believe that there are three
categories of storage duration, or lifetime, for objects: automatic,
static, and allocated. Precise definitions are in the Standard itself,
but a rough outline might be:

- Allocated: Objects are requested and released by the programmer during
execution through the memory management functions. This might or might
not be what a particular environment refers to as "heap" storage, but
that could be incomplete as a generalization. 'malloc' and 'free' are
examples of memory management functions in C. The number of these
objects and the storage required for them is something that can vary
during execution.

- Static: Objects have guaranteed accessibility for the duration of the
program's execution. We know at translation-time (compile-time) the
number of such objects and the storage required for them.

- Automatic: Objects which are established and expire based on a
particular scope within the program, such as within function bodies.
They could be considered "automatic" in the sense that when their scope
ends, so do they expire. Their storage do not require any effort to
release beyond writing a program where every scope has a beginning and
an end. This might or might not be what a particular environment refers
to as "stack" storage, but that could be incomplete as a generalization.
The number of such objects and the storage required for them can
vary during program execution (run-time).

void func(void) {
auto int i; /* i is automatic */
{
auto int j; /* j is automatic */
other_func(); /* j's lifetime continues... */
/* ...into other_func()'s execution */
}
/* j's lifetime has expired */
}
/* i's lifetime has expired */

I don't believe that C prevents nor denies other forms of storage
reservation that your C implementation or OS might define, but you might
benefit by inquiring specifically about such environments.

Hope this helps.