Object Lifetime and Destructors

Every time a program passes a container to a function, returns one, or stores one in another variable, it has to decide what happens to the data inside. The container might be duplicated, so that two independent objects hold the same elements. Or its contents might be handed over to a new owner, so that the original no longer holds them. These two choices are the subject of copy and move semantics.

Read the next few sections with one question in mind: after this operation finishes, how many objects are responsible for the data, and what state is each one in? Almost every rule about copying, moving, and destroying objects is an answer to that question.

Copying a container creates a second container that holds the same values as the first. Afterward the two containers are separate objects. Changing an element in one does not change the element in the other. Copying is the operation that produces this independent second object, and it is the default way to make a duplicate when no other choice has been made explicitly.

The important point is that both containers remain usable and independent. Each one is responsible for its own elements. Because the elements must be duplicated, a copy can take more time and memory than the original took to create, especially when the container is large.

Moving a container transfers its contents to a new container instead of duplicating them. The destination takes over the data, and the source is left in a valid but unspecified state. A move is useful when the source is no longer needed, because the program avoids building a second copy of the elements. This is why a move can be cheaper than a copy: no elements need to be duplicated, because the existing data changes hands.

In C++ code, the move is requested by casting the source to an rvalue reference with std::move. This tells the language that the source may give up its contents.

A container usually owns a resource, such as a block of memory that holds its elements. Copy and move operations decide what happens to that resource. A copy must give the new object its own resource, so that two objects never release the same memory. A move hands the existing resource to the new object and leaves the source without it, so that only one object is responsible for it at any time.

Keeping track of which object owns the resource is what prevents leaks and double releases. A leak happens when a resource is never released. A double release happens when two objects both try to release the same resource. Copies avoid the second problem by creating new resources, and moves avoid it by transferring the single existing resource.

Copy and move behavior is controlled by a small group of special member functions. Together they describe how an object is created from another object, how an existing object is assigned from another, and how an object is cleaned up. The essential operations are the copy constructor, the copy assignment operator, the move constructor, the move assignment operator, and the destructor.

The constructors create a new object, while the assignment operators replace the value of one that already exists. A copy version takes a read-only reference to its source, and a move version takes a reference that allows the source to be emptied. The destructor is the step that releases what the object owns. Seeing these operations as a set makes it clear that copying and moving are two forms of the same job, producing a new value from an existing one, and that destruction is what ends the object's ownership.

Sometimes a class should not be copied or moved at all. A handle that represents a unique external resource, or an object whose identity matters, may be wrong to duplicate. Suppressing an operation means stating that the operation is not available, so that code which tries to use it fails to compile instead of silently producing an incorrect result. Choosing to allow or suppress an operation is a design decision about what the class means.