Mismatched new/delete calls in the constructor and destructor of a class. The obvious case of C++ memory leakage occurs when a developer dynamically allocates memory via new and forgets to explicitly clean up that memory with a call to delete. This can occur when an object is created on the heap and not explicitly cleaned up or, more commonly, when the constructor of a class dynamically allocates memory but the destructor is either absent or not cleaning up the object correctly. An example of the former case is shown here.

Nested object pointers that are not cleaned up properly. A less obvious pitfall exists when one object contains another object by reference instead of by value. In the example code shown here, a Meal object contains a Melon object by reference (i.e., a Meal contains a pointer to a Melon). This Melon is dynamically allocated in the Meal's constructor and therefore must be deallocated in its destructor. The confusion occurs when a developer thinks that the Melon's destructor is called automatically by the Meal's destructor. Automatic destructor calls will occur when one object contains another by value. In our example, this would translate to a Meal object that contains a Melon object (i.e., by value).

Deleting an array of objects without using the square brackets on delete. A common point of confusion for C++ novices involves the use of the square brackets on the delete function; for example, delete[] p versus delete p. This size argument is unnecessary for deleting a single object, a single primitive data type (e.g., int, char, short), or an array of a primitive type. It is required for deleting arrays of any object that has a destructor defined on it. Variable-sized objects are a particularly vulnerable category of objects affected by this constraint. A variable-sized object is an object that contains a pointer to dynamically allocated space. (Note: For a more detailed discussion of variable-sized classes/objects and their ramifications, see “Towards a Minimal Public Interface for C++ Classes” and “A Framework for Variable-Sized Classes,” The C++ Insider, Vol. 1, nos. 1 and 2, respectively.) The square brackets tell the compiler that the pointer is pointing to a vector of objects and that the destructor must be called along with the proper values for the object addresses (i.e., &array[0], &array[1], &array[2], etc.). If the brackets are not provided, then the pointer is assumed to be pointing at one object. The additional objects in the array will not have their destructors called, resulting in memory leakage. If a number is placed between the square brackets and is larger than the size of the array, then the compiler will call the destructor on invalid objects (memory overflow), resulting in heap corruption. If a number between square brackets is smaller than the size of the array, the compiler will not call the necessary number of constructors, resulting in memory leakage.

In all cases of memory leakage due to missing square brackets, the space taken up by the class (sizeof (class_name)) is put back on the heap because of the nature of new and delete. For this reason, some C++ developers claim the size argument is unnecessary for classes that do not have destructors defined on them. This is a dangerous coding convention since many such classes become variable-sized or have destructors added as the application matures. For example, a Point class containing two integer data members (x and y) might get a dynamically allocated string called color, (see Figure B.1), or a Meal class might add a melon pointer or even a melon object.

Figure B.1. Graphical representation of memory leak #3.

Some developers consider this memory leakage problem to be the worst because it cannot be eliminated by the class implementor since C++ is a multiparadigm language (i.e., it contains nonclass/object entities. In a pure system, an array class would handle the deletion correctly for all users. Of course, arrays could be made a C+ + class for a given application, eliminating this particular memory leakage problem.

Arrays of pointers to objects are not arrays of objects. Another point of confusion related to the use of delete's square brackets is the fact that destroying arrays of object pointers is very different from destroying arrays of objects. As was shown in the preceding code, the square brackets on the delete function control the proper calls to each object's destructor when used for destroying arrays of objects. Some developers attempt to use the size argument as a method for controlling proper destructor calls for objects stored in arrays of pointers to objects. Adding a size argument to the delete call on an array of pointers to objects simply tells the compiler the number of pointers to destroy. Since pointers are considered primitive types in C++, this argument has no effect on destructor calls. The pointers are placed back on the heap, but all of the objects are kept in their allocated state. The result is memory leakage.

Missing copy constructors. If the user of a C++ class attempts to invoke a constructor function that the implementor of that class has not defined, then the user expects to get an error from the compiler or, at a minimum, the linker. This is normally the case in C++, unless that constructor happens to be the copy constructor (also called the initialization constructor). The copy constructor is a constructor function whose sole argument is a reference to an object of the constructor's class. For example, the prototype of the copy constructor for the Point class looks like Point (const Point&);. If this constructor is not defined, then the compiler assumes its definition to be a memberwise copy of the data members (bitwise copy in C++ version 1.2). Unfortunately, memberwise (or bitwise) copying of a pointer is defined as copying the address from one location to another. The ramifications of this implicit pointer copying is that two objects will have pointers to the same dynamically allocated memory. When the first object is destroyed, its destructor will clean up the dynamically allocated memory associated with it. When the second object is destroyed, its destructor attempts to clean up the same memory. Deleting the same memory twice is considered an error and will probably corrupt the heap. A developer may argue that, by convention, no user of his or her class will call the copy constructor. Aside from the usual folly of programming by convention, there are issues dictating that a copy constructor be explicitly defined. Most calls to the copy constructor are not explicit calls. The copy constructor is called whenever one object is initialized to another of the same type, an object is passed by value as an argument to a function, or an object is returned by value from a function. This implicit behavior will cause memory leakage in variable-sized classes.

Missing overloaded assignment operator. The memory leakage problem associated with a missing overloaded assignment operator is similar to the problem associated with the missing copy constructor. When an operator is used on an object of a class, the compiler (or linker) will generate an error if that operator is not overloaded for that class. The C++ language makes an exception with the assignment operator. If the user does not specify its functionality, then C++ guesses that the user wants to perform a memberwise copy (bitwise copy in versions 1.2 and earlier). If the class is variable-sized, then the result is memory leakage. The actual leakage occurs when the object on the left-hand side of the assignment operator has its internal address overlayed with the internal address of the object on the right-hand side of the operator. The memory to which the left-hand side points is no longer referenced but is still allocated. In addition, the two operand objects point at the same dynamically allocated memory (see Figure B.2). This will probably cause heap corruption when the destructor for the class is invoked by each object (at some later execution time) and each invocation attempts to delete the same address.

Figure B.2. Memory leakage due to a missing assignment operator.

General confusion concerning the overloading of nonmodifying operators. A nonmodifying operator is an operator that does not affect any of its operands and evaluates to an object of the same type as the operands. Typical examples include the mathematical operators like addition (+), subtraction (-), multiplication (*), division (/), and modulus (%). Relational operators are not considered nonmodifying, because they always evaluate to type boolean regardless of the data types being compared. In addition, assignment operators (e.g., =, +=, <<=) are not nonmodifying, because these operators affect their left-hand-side operand.

Memory leakage associated with incorrectly implemented, nonmodifying operators is the type of problem that either is nonexistent in an application or appears in almost every class. This discrepancy is due to the fact that it revolves around invalid assumptions about overloaded operators. The main issue involved with the implementation of nonmodifying operators revolves around the return value. For the sake of efficiency, a C++ developer may decide to return the evaluated result by reference instead of by value. (Recall that returning an object by value will implicitly call the copy constructor, costing runtime.) A first attempt at designing such an operation might be to build the evaluated result in a temporary variable and return it by reference. The Point example in the code here illustrates the fact that returning a local object by reference is an error since the memory associated with the reference is returned to the stack upon exit from the function. The caller is left with a returned reference to an invalid, deallocated object.

#include <iostream.h> 
class Point {
 int x, y;
 char* color;
public:
 Point(int = 0, int = 0, char* = ''Red''),
 ~Point();
 Point (const Point&);
 void print();
 const Point& operator=(const Point&);
 const Point& operator+(const Point&);
};
void
Point::print()
{
 cout << ''I live at ('';
 cout <<x<<'', ''<<y<<'') and '';
 cout << ''I'm'' << color <<''.
";
}
const Point&
Point::operator=(const Point& rhs)
{
 x = rhs.x; y = rhs.y;
 delete color;
 color = new char[strlen(rhs.color)+1];
 strcpy(color, rhs.color);
}
// This function returns a hidden pointer
// (i.e., a reference) to a temporary Point
// object that will be destroyed upon return
// from the function.
const Point&
Point::operator+(const Point& rhs)
{
 Point temp;
 temp.x = x + rhs.x; temp.y = y + rhs.y;
 delete temp. color;
// Not exactly a good color-mixing scheme!
 temp.color = new char[strlen(color)+strlen(rhs.color)+1];
 sprintf(temp.color, ''%s%s'', color, rhs.color);
 return(temp);
main()}
{
 Point p1(10, 10, ''Blue''),
 Point p2(20, 60, ''Green''),
// The copy constructor is receiving a destroyed
// Point object as an argument since the operator+
// function returns a hidden pointer to the
// automatic variable temp. This variable had its
// destructor called upon exit from operator+.
 Point p3 = p1 + p2;

 p3.print();
}

Another attempt at a solution to this problem is to make the temporary Point object of internal static storage class. An internal static object is not created and destroyed upon entrance/exit from the function; it simply goes in and out of scope. This code will work fine, provided the operator is never used in a nested function call. Of course, one can imagine all sorts of uses for nesting addition operators. The C++ statement x+y+z is one of the more mundane yet valid examples. Because each call to operator+ uses exactly the same temporary Point object, the nested calls will stomp the memory of each other.

#include <iostream.h> 
class Point {
 int x, y;
 char* color;
public:
 Point(int = 0, int = 0, char* = ''Red''),
 ~Point();
 Point(const Point&);
 void print();
 const Point& operator=(const Point&);
 const Point& operator+(const Point&);
};
const Point&
Point::operator+(const Point& rhs)
{
// Note the use of the internal static storage class
// for temp. Each caller to this function reads and
// writes exactly the same Point object.
 static Point temp;
 temp.x = x + rhs.x; temp.y = y + rhs.y;
 delete temp.color;
//Not exactly a good color-mixing scheme!
 temp.color = new char[strlen(color)+strlen(rhs.color)+1];
 sprintf(temp.color, ''%s%s'', color, rhs.color);
 return(temp);
}

Taking a step back to examine the relevant problems of each example, we realize that we need a completely separate Point object upon each invocation of the operator, yet its existence must include the scope of the operator's return value. The logical choice is to dynamically allocate the new Point object from within the overloaded operator and to return a Point reference to it.

#include <iostream.h> 
class Point {
 int x, y;
 char* color;
public:
 Point(int = 0, int = 0, char* = ''Red''),
 ~Point();
 Point(const Point&);
 void print();
 const Point& operator=(const Point&);
 const Point& operator+(const Point&);
};
const Point&
Point::operator+(const Point& rhs)
{
 Point *temp = new Point;
 temp->x = x + rhs.x;
 temp->y = y + rhs.y;

// This deletion is necessary due to the nature
// of calling the constructor for Point with
// zero arguments.
 delete temp->color;

// Not exactly a good color-mixing scheme!
temp->color = new char[strlen(color)+
        strlen(rhs.color)+1];
sprintf(temp->color, ''%s%s'', color, rhs.color);
 return(*temp);
}

The C++ developer writing this software tests it extensively (complete with nested calls) and finds that it works flawlessly. It is shipped to numerous clients, some of whom begin complaining of memory leakage problems. Where is this memory leakage? This problem is best illustrated by posing the question, “Where is the temp object, which is dynamically allocated upon each invocation of Point::operator+, cleaned up?” Its destructor is not called automatically since pointers never invoke an object's destructor implicitly. The caller cannot explicitly call the Point object's destructor since the address of the object is not available. Consider the C++ code z = x + y;. How does a user retrieve the address of the temp object?

The answer, of course, is that he or she cannot retrieve the address and, therefore, cannot destroy the temp object. The temp object created upon each invocation of Point::operator+ is leaked from the application and cannot be retrieved.

Our initial premise, that we need to return a reference to a Point object from Point::operator+, was an error. As it turns out, nonmodifying operators must always return an object and not a reference to an object. The object returned is of the automatic storage class.

Forgetting to make the destructor of a base class virtual. The eighth memory leakage error with which a C++ developer needs to be concerned involves the use of virtual destructors. Developers will often use inheritance to create a taxonomy of classes for the purpose of treating the very different leaf classes as a homogeneous set (e.g., treating the very different apple, banana, and orange objects as a homogeneous collection of fruit). This homogeneous collection of fruit is implemented as an array of fruit pointers, where each fruit pointer points at a particular type of fruit object (i.e., an apple, banana, or orange object). Eventually, the delete function must be called on each of the fruit pointers in order to destroy the fruit type to which it points. The main question is which destructor will be called when the statement, delete basket[i] is invoked at runtime (assume basket is the array of fruit pointers). If the destructor for fruit, namely, Fruit:: ~Fruit(), is not virtual, then each time the delete statement is invoked, it is calling the destructor for fruit. If the destructor for fruit is marked virtual (polymorphic), then the correct destructor for the particular type of fruit is invoked at runtime (i.e., Apple objects call Apple::~Apple(), Banana objects call Banana::~Banana()). If any of the leaf classes (in this example, apples, bananas, and oranges) contain pointers to dynamically allocated space, then a nonvirtual base class destructor (in this example, Fruit::~Fruit) will result in memory leakage, since the destructor for the leaf class is never called (see Figure B.3). The following example illustrates this problem, using Fruit, Apple, and Banana.

Figure B.3. Graphical example of memory leakage due to a nonvirtual destructor (memory for "Rome", "Cuba", and "Mac" is leaked off the heap).