Item 27: Requiring or prohibiting heap-based objects

Sometimes you want to arrange things so that objects of a particular type can commit suicide, i.e., can “delete this.” Such an arrangement clearly requires that objects of that type be allocated on the heap. Other times you’ll want to bask in the certainty that there can be no memory leaks for a particular class, because none of the objects could have been allocated on the heap. This might be the case if you are working on an embedded system, where memory leaks are especially troublesome and heap space is at a premium. Is it possible to produce code that requires or prohibits heap-based objects? Often it is, but it also turns out that the notion of being “on the heap” is more nebulous than you might think.

Requiring Heap-Based Objects

Let us begin with the prospect of limiting object creation to the heap. To enforce such a restriction, you’ve got to find a way to prevent clients from creating objects other than by calling new. This is easy to do. Nonheap objects are automatically constructed at their point of definition and automatically destructed at the end of their lifetime, so it suffices to simply make these implicit constructions and destructions illegal.