Defining Custom Copy Semantics

Copying an object usually feels like the simplest operation in a program. You write one line that gives a new name to a value, and you expect two independent things to exist afterward. For many ordinary types that expectation is correct. For one important family of classes it is not, and the failure is quiet: the program compiles, runs, and produces wrong results only when one of the two objects is changed later. This article is about the gap between what a copy looks like and what it actually does.

The running scenario comes from a Vector class whose objects own a collection of elements. Assigning one Vector to another is written as a single line, and the reader's first instinct is to assume the second Vector receives its own elements. The rest of this article tests that instinct, because the language's default behavior does not guarantee it.

The misconception to clear up is that a class's default copy behavior is correct for that class. It is correct for classes whose members are plain values, such as a number or a flag. It is not automatically correct for a class whose object reaches its data through a pointer. Once a pointer is copied, two objects hold the same route, and nothing in the default copy says which object is responsible for the data at the end of that route.

Trace the scenario one step at a time. Each Vector object holds a pointer to its elements, and the sz member records how many there are. Before the copy, v1 leads to a set of four elements. The default copy then initializes v2 member by member. Its pointer receives the same value that v1's pointer has, so v2 now leads to the same set of four elements. No new elements are created.

The diagram shows the state the copy produces. Two objects exist, but only one array of elements exists. Each object's elem member is a copy of the same pointer value, so there is one resource with two routes into it.

A handle carries an invariant, which is a property it is supposed to keep true at all times. For a resource handle, the invariant concerns ownership of the resource. Default memberwise copy can break that invariant, because after the copy the program has two handles and only one arrangement of storage, with neither handle clearly owning it alone. That is the precise sense in which the default behavior is a disaster for this kind of class.

A resource handle is responsible for an object reached through a pointer. Default copying leaves two handles sharing one resource, and that sharing is what breaks the invariant. The fix is not to tweak the result of the copy after the fact. The copy behavior of such a class must be defined deliberately, rather than left to whatever the default produces.

A destructor is the place where a class cleans up the resource it owns when an object goes away. If a class needs to release something at the end of its life, it is almost always because it owns that something. Ownership is exactly what default copying muddles, since two objects end up pointing at one resource. So when a class has a destructor, a programmer should treat the default copy behavior with suspicion.

The source makes the same point from the compiler's side: the presence of a destructor is a strong hint that default memberwise copy semantics is wrong, and the compiler should at least warn about an example like this one. A destructor does not prove a bug, but it is the signal to review copy behavior on purpose.

When you copy an object of a class, the language needs to know exactly how that copy should be produced. The answer is not a single rule. Copying an object of a class is defined by two members working together: a copy constructor and a copy assignment. Together these two members form the definition of copying for that class, and they are the place to look whenever you want to understand what a copy of one of your objects will actually contain.

The declaration above is abridged to the parts the source names: the private data, the copy members, and the destructor. The source presents the whole class as a list of responsibilities, with the copy members as the two lines that define copying.

Suppose a program behaves unexpectedly with Vector objects after one of them is copied. A practical first step is to ask which declaration governs the copy. Because copying is defined by the copy constructor and copy assignment, 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.