C++ Memory and Resource Management
- Failure to Distinguish Scalar and Array Allocation
- Checking for Allocation Failure
- Replacing Global New and Delete
- Confusing Scope and Activation of Member new and delete
- Throwing String Literals
- Improper Exception Mechanics
- Abusing Local Addresses
- Failure to Employ Resource Acquisition Is Initialization
- Improper Use of auto_ptr
This chapter is from the book
This chapter is from the book
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:
int *ip = new int(12); // . . . free( ip ); // wrong! ip = static_cast<int *>(malloc( sizeof(int) )); *ip = 12; // . . . delete ip; // wrong!
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:
class Widget {
public:
void *operator new( size_t );
void operator delete( void *, size_t );
// . . .
};
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:
Widget *w = new Widget( arg ); // OK // . . . delete w; // OK w = new Widget[n]; // oops! // . . . delete [] w; // oops!
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:
class Widget {
public:
void *operator new( size_t );
void operator delete( void *, size_t );
void *operator new[]( size_t n )
{ return ::operator new[](n); }
void operator delete[]( void *p, size_t )
{ ::operator delete[](p); }
// . . .
};
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.