Object landscapes and lifetimes

Technically, OOP is just about abstract data typing, inheritance and polymorphism, but other
issues can be at least as important. The remainder of this section will cover these issues.
One of the most important factors is the way objects are created and destroyed. Where is the
data for an object and how is the lifetime of the object controlled? There are different
philosophies at work here. C++ takes the approach that control of efficiency is the most
important issue, so it gives the programmer a choice. For maximum run-time speed, the
storage and lifetime can be determined while the program is being written, by placing the
objects on the stack (these are sometimes called automatic or scoped variables) or in the static
storage area. This places a priority on the speed of storage allocation and release, and control
of these can be very valuable in some situations. However, you sacrifice flexibility because
you must know the exact quantity, lifetime and type of objects while you’re writing the
program. If you are trying to solve a more general problem such as computer-aided design,
warehouse management or air-traffic control, this is too restrictive.
The second approach is to create objects dynamically in a pool of memory called the heap. In
this approach you don’t know until run time how many objects you need, what their
lifetime is or what their exact type is. Those are determined at the spur of the moment while
the program is running. If you need a new object, you simply make it on the heap at the
point that you need it. Because the storage is managed dynamically, at run time, the amount
of time required to allocate storage on the heap is significantly longer than the time to create
storage on the stack. (Creating storage on the stack is often a single assembly instruction to
move the stack pointer down, and another to move it back up.) The dynamic approach
makes the generally logical assumption that objects tend to be complicated, so the extra
overhead of finding storage and releasing that storage will not have an important impact on
Chapter 1: Introduction to Objects 51
the creation of an object. In addition, the greater flexibility is essential to solve the general
programming problem.
C++ allows you to determine whether the objects are created while you write the program
or at run time to allow the control of efficiency. You might think that since it’s more flexible,
you’d always want to create objects on the heap rather than the stack. There’s another issue,
however, and that’s the lifetime of an object. If you create an object on the stack or in static
storage, the compiler determines how long the object lasts and can automatically destroy it.
However, if you create it on the heap the compiler has no knowledge of its lifetime. A
programmer has two options for destroying objects: you can determine programmatically
when to destroy the object, or the environment can provide a feature called a garbage
collector that automatically discovers when an object is no longer in use and destroys it. Of
course, a garbage collector is much more convenient, but it requires that all applications
must be able to tolerate the existence of the garbage collector and the other overhead for
garbage collection. This does not meet the design requirements of the C++ language and so
it was not included, but Java does have a garbage collector (as does Smalltalk; Delphi does
not but one could be added. Third-party garbage collectors exist for C++).
The rest of this section looks at additional factors concerning object lifetimes and landscapes.