Stephen Dewhurst discusses how the various features of C++ are used together in memory management, how they sometimes interact in surprising ways, and how to simplify their interactions.

Purchase this book through the end of January and receive four exclusive sample chapters from forthcoming books by some of technology's greatest luminaries. For more information, check http://www.expectsomethingbetter.com.

This chapter is from the book

C++ offers tremendous flexibility in managing memory, but few C++ programmers
fully understand the available mechanisms. In this area of the language,
overloading, name hiding, constructors and destructors, exceptions, static and
virtual functions, operator and non-operator functions all come together to
provide great flexibility and customizability of memory management.
Unfortunately, and perhaps unavoidably, things can also get a bit complex.

In this chapter, we'll look at how the various features of C++ are used
together in memory management, how they sometimes interact in surprising ways,
and how to simplify their interactions.

Inasmuch as memory is just one of many resources a program manages,
we'll also look at how to bind other resources to memory so we can use
C++'s sophisticated memory management facilities to manage other resources
as well.

Gotcha #60: Failure to Distinguish Scalar and Array Allocation

Is a Widget the same thing as an array of Widgets? Of
course not. Then why are so many C++ programmers surprised to find that
different operators are used to allocate and free arrays and scalars?

We know how to allocate and free a single Widget. We use the
new and delete operators:

Widget *w = new Widget( arg );
// . . .
delete w;

Unlike most operators in C++, the behavior of the new operator
can't be modified by overloading. The new operator always calls a
function named operator new to (presumably) obtain some storage, then
may initialize that storage. In the case of Widget, above, use of the
new operator will cause a call to an operator new function
that takes a single argument of type size_t, then will invoke a
Widget constructor on the uninitialized storage returned by
operator new to produce a Widget object.

The delete operator invokes a destructor on the Widget and
then calls a function named operator delete to (presumably) deallocate
the storage formerly occupied by the now deceased Widget object.

Variation in behavior of memory allocation and deallocation is obtained by
overloading, replacing, or hiding the functions operator new and
operator delete, not by modifying the behavior of the new and
delete operators.

We also know how to allocate and free arrays of Widgets. But we
don't use the new and delete operators:

w = new Widget[n];
// . . .
delete [] w;

We instead use the new [] and delete [] operators
(pronounced "array new" and "array delete"). Like
new and delete, the behavior of the array new and array delete
operators cannot be modified. Array new first invokes a function called
operator new[] to obtain some storage, then (if necessary) performs a
default initialization of each allocated array element from the first element to
the last. Array delete destroys each element of the array in the reverse order
of its initialization, then invokes a function called operator delete[]
to reclaim the storage.

As an aside, note that it's often better design to use a standard
library vector rather than an array. A vector is nearly as
efficient as an array and is typically safer and more flexible. A
vector can generally be considered a "smart" array, with
similar semantics. However, when a vector is destroyed, its elements
are destroyed from first to last: the opposite order in which they would be
destroyed in an array.

Memory management functions must be properly paired. If new is used
to obtain storage, delete should be used to free it. If malloc
is used to obtain storage, free should be used to free it. Sometimes,
using free with new or malloc with delete
will "work" for a limited set of types on a particular platform, but
there is no guarantee the code will continue to work:

The same requirement holds for array allocation and deletion. A common error
is to allocate an array with array new and free it with scalar delete. As with
mismatched new and free, this code may work by chance in a
particular situation but is nevertheless incorrect and is likely to fail in the
future:

double *dp = new double[1];
// . . .
delete dp; // wrong!

Note that the compiler can't warn of an incorrect scalar deletion of an
array, since it can't distinguish between a pointer to an array and a
pointer to a single element. Typically, array new will insert information
adjacent to the memory allocated for an array that indicates not only the size
of the block of storage but also the number of elements in the allocated array.
This information is examined and acted upon by array delete when the array is
deleted.

The format of this information is probably different from that of the
information stored with a block of storage obtained through scalar new. If
scalar delete is invoked upon storage allocated by array new, the information
about size and element countwhich are intended to be interpreted by an
array deletewill probably be misinterpreted by the scalar delete, with
undefined results. It's also possible that scalar and array allocation
employ different memory pools. Use of a scalar deletion to return array storage
allocated from the array pool to the scalar pool is likely to end in
disaster.

delete [] dp; // correct

This imprecision regarding the concepts of array and scalar allocation also
show up in the design of member memory-management functions:

The author of the Widget class has decided to customize memory
management of Widgets but has failed to take into account that array
operator new and delete functions have different names from their scalar
counterparts and are therefore not hidden by the member versions:

Because the Widget class declares no operator new[] or
operator delete[] functions, memory management of arrays of
Widgets will use the global versions of these functions. This is
probably incorrect behavior, and the author of the Widget class should
provide member versions of the array new and delete functions.

If, to the contrary, this is correct behavior, the author of the class should
clearly indicate that fact to future maintainers of the Widget class,
since otherwise they're likely to "fix" the problem by providing
the "missing" functions. The best way to document this design decision
is not with a comment but with code:

The inline member versions of these functions cost nothing at runtime and
should convince even the most inattentive maintainer not to second-guess the
author's decision to invoke the global versions of array new and delete
functions for Widgets.