Constructors and Destructors for Resource Handles

When you write a class, you usually expect that copying one of its objects will produce a sensible second object. For simple fields that expectation holds without any extra work. Many useful classes, however, do not hold all of their data in their own fields. They hold a handle, such as a pointer, that refers to a resource that lives somewhere else. Copying such an object is no longer a simple matter of copying fields, because the resource itself has to be considered as well.

This article uses a class called Vector to show how C++ handles that situation. Vector is a container, which means an object that holds a collection of elements. It stores its elements in an array obtained with new, and it releases that array in its destructor. Two members of the class, the copy constructor and the copy assignment operator, together define what a copy of a Vector contains. By the end of this article you should be able to find those two members, read their declarations, trace when the resource is acquired and released, and explain the RAII technique that ties these steps together.

The Vector class holds two data members. The member elem is a pointer to an array of doubles, and sz records how many doubles there are. The array itself is not stored inside the Vector object. It lives on the free store, and the Vector refers to it through elem. This arrangement is called the handle-to-data model: a small object holds a pointer and a count, and the larger block of data it refers to is kept elsewhere.

The model is useful when data can change size during an object's lifetime. The Vector object stays small and fixed in size no matter how many elements it refers to, while the elements can live in a block that is sized to fit them. The handle is the small object the program actually holds. The data is the larger block the handle points to. Because the destructor knows where that block begins through elem, it can release the whole block in one step.

This is the reason copying needs attention. A copy of a Vector must deal with the array as well as with the fields. Whatever the class decides to do about that array is part of the class's copying behavior, and the class has to say what that behavior is.

Copying an object of a class is defined by two members working together: a copy constructor and a copy assignment operator. Together they form the definition of copying for that class. They are the place to look whenever you want to understand what a copy of one of your objects will actually contain. The two members are separate declarations inside the class, and each one handles a different kind of copy.

The two copy members are easy to confuse because they take the same parameter. What separates them is when each one runs. The copy constructor runs when a brand-new object is created from an existing one. The copy assignment runs when an object that already exists is overwritten with the value of another. Both members are declared inside the same class, and both determine what the copy contains.

The source presents the Vector class as a list of responsibilities: private data, constructors and destructor, copy members, and element access functions. The copy members are the two lines that define copying. The listing below keeps the parts discussed here. The element access functions are omitted because they do not decide how a copy is produced.

Notice the two differences in the copy lines. The copy constructor has no return type and carries the class name, which marks it as a constructor. The copy assignment has a return type of Vector& and carries the name operator=, which marks it as the assignment operator. Both take a const Vector& parameter, so both read their source without modifying it.

Consider what would happen if a copy duplicated only the handle. The new object would receive the same pointer value as the original, and so both objects would refer to the same array on the free store. The diagram below shows that situation. It is a useful question to ask of any class that manages a resource: after a copy, what do the two objects refer to, and who is responsible for the resource when each object ends its life?

In this picture the two objects share one array. Whichever object is destroyed first would release an array the other object still refers to. The source does not describe a default copy in detail, so the diagram shows the hypothetical case that motivates the design. The practical lesson stands regardless: a class that holds a handle must say how its copies deal with the resource, and it does so in the copy constructor and copy assignment.

Suppose a program behaves unexpectedly with Vector objects after one of them has been copied. A practical first step is to ask which declaration governs the copy. Because copying is defined by the copy constructor and copy assignment, you check those two declarations in the Vector class and confirm which member the copying operation would use. The rest of the class, such as the element access functions, does not decide how the copy is produced, so it is rarely the first place to look.

The constructor and destructor work as a pair. The constructor Vector(int s) asks the free store for an array of s doubles, stores the pointer in elem, records the count in sz, and fills every slot with zero. The destructor ~Vector() hands that same array back with delete[]. Whatever the constructor takes from the free store, the destructor is responsible for returning. The timeline below follows one Vector through a single function call.

Users of Vector never call the destructor themselves. They create and use Vector objects much as they would variables of built-in types, and the cleanup happens without their intervention. The rules for naming, scope, allocation, and lifetime that apply to an int or a char also apply to a Vector, so the destructor runs as the object's lifetime ends.

A destructor is the member that releases a resource. Its name is the tilde character, written ~, followed by the class name, so the destructor for Vector is ~Vector(). The name mirrors the constructor's name, which is the class name alone. In the class body, the constructor and destructor sit side by side: Vector(int s) acquires and ~Vector() releases. The tilde is the only character that distinguishes the destructor's name from the constructor's name.

Before you see the program below run, think about the order of events. The class has a constructor and a destructor, each of which prints one line. The program prints a line before an inner block, creates one object inside that block, and prints a line after the block.

The constructor and destructor combination is the basis of most C++ general resource management techniques. The best-known of these is Resource Acquisition Is Initialization, usually abbreviated RAII. RAII is the technique of acquiring a resource in a constructor and releasing it in a destructor. The name describes the core idea: the act of acquiring the resource happens as part of initializing an object.

The before column shows acquisition and release written as two separate calls in general-purpose code. Each call has to be remembered and paired correctly by the programmer. The after column shows the same resource handled by a class. The constructor acquires it, and the destructor releases it when the object's lifetime ends. The release is attached to the object's scope, so it does not depend on the programmer remembering to write it.

The payoff is that RAII lets you eliminate what the source calls naked new operations and naked delete operations. A naked new is an allocation sitting in general-purpose code. A naked delete is a release written by hand in that same code. RAII keeps allocations buried inside the implementation of a well-behaved abstraction, such as Vector, so that everyday code does not have to remember to clean up. Avoiding naked new and naked delete makes code far less error-prone and far easier to keep free of resource leaks.