Destructors and Ending an Object's Lifetime

Imagine a program that builds a Vector holding a million double values. At some point that vector has to leave the scope where it was created and arrive in a different scope, where another part of the program will use it. The question that matters is what happens to those million values during that trip. Do they get rebuilt, duplicated, or handed over?

The rest of this article follows that question through the lifecycle of an object. You will see how a class decides what happens to the resource it holds when the object is created, when it is copied, when it is moved, and when it finally goes out of use.

Many classes hold something that is expensive or unusual to own. Examples from the source include a block of memory, a container full of elements, and a handle to an activity running alongside the rest of the program. Every such holding has a beginning, a period of use, and an end.

The central question is simple to state: when an object moves between places in a program, or when it goes out of use, what should happen to the resource it is holding? The answer depends on the resource. Some resources can be duplicated without trouble, some should not be duplicated because doing so is wasteful, and some cannot be duplicated at all. The language gives the class author a set of operations for expressing which case applies.

The purpose of these tools is to make those decisions explicit, instead of leaving them to chance. A class that does not state what happens to its resource at each stage leaves the behavior to whatever default happens to apply.

A class author can take full control over the lifetime of a contained resource by defining four kinds of operation. Taken together, these four operations are the complete set of hooks the class author has for deciding what happens to the resource at every stage.

The four operations are not independent of one another. Each one answers a different question about the same resource. The constructor answers how the resource begins, the copy operations answer how it may be duplicated, the move operations answer how it may be handed over, and the destructor answers when it is released. The diagram below shows how these four hooks surround the held resource.

Of the four operations, the move operations are the focus of this topic, because they answer a question the copy operations cannot answer cheaply. Copying is the operation that creates a second, independent object. Moving is the operation that relocates the resource itself, so that the receiving object takes over what the original was holding.

Both operations move an object's value from one place in the program to another, but they differ in what they must do with the underlying resource. The table below summarizes that contrast using only what the source supports.

Some objects cannot be copied at all, and some can be copied but should not be, because the copy would be too costly. The source gives two concrete examples. Both are useful for deciding when a move is the right choice.

A move constructor is the operation that lets an object move simply and cheaply from one scope to another. Its defining feature is cheapness: the object's resource is handed over rather than rebuilt. Follow the vector from the previous section through a move.

Before the move, the source scope is the one whose object holds the million doubles. The move constructor runs, and the destination scope ends up holding the vector. The point to notice is that the elements do not have to be duplicated along the way, which is exactly what made copying undesirable in the first place.

Notice what the diagram does not contain: a second group of a million doubles. That absence is the whole point. A move leaves the contents where they are and changes which object is responsible for them. A copy, by contrast, would produce a second set of elements, which is the cost the programmer wanted to avoid.

An object's lifetime can be followed as a sequence of states. It begins when the constructor sets it up. It may then be copied, which produces a second independent object, or moved, which hands the resource to another object. Once the object's lifetime comes to an end, the destructor runs and releases the resource it holds.

The destructor is the last of the four operations. It runs when the object's lifetime comes to an end, which is when the object goes out of use at the end of its scope. Its job is to release the held resource. A source object that has been moved from no longer holds the resource, so its destructor has nothing to release, and it still runs safely.

The decision depends on the resource. The source describes three cases: some resources can be duplicated without trouble, some should not be duplicated because doing so is wasteful, and some cannot be duplicated at all. Those three cases map onto a practical way of thinking about the choice.