Pointers and Object Ownership

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 that gap between what a copy looks like and what it actually does.

The 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 natural 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.

Default memberwise copy works by copying each member of an object one at a time. Nothing about this process is special: the copy operation walks through the object's members and duplicates each one into the new object. The rule is simple, and for a class whose members hold plain values it is exactly what you want. If an object holds a plain integer, the new object gets its own integer with the same value, and changing one does not affect the other.

The trouble starts when a member is not the data itself but a pointer that leads to data stored elsewhere. Copying the pointer copies the route to the data, not the data. After the copy, the two objects have two pointer members with identical values, and those values point at the same storage. The copy looks complete from the outside, because every member has been duplicated, yet the thing the members refer to has not been duplicated at all.

Compare two members. A plain int member is copied by value: the new object receives a value, and that value is stored in a separate place. A pointer member is copied as an address: the new object receives the same address, and both objects are now routes to one target. The same copy operation produces independent results for one member and shared results for the other.

The clearest way to see the shared resource is to follow the copy one step at a time. The trace below uses the Vector scenario from the opening. Each step names what changes, so you can check exactly where the two objects begin sharing one set of elements.

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. A healthy handle has a clear answer to the question of who owns the resource it leads to. 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.

The transition from one owner to two sharers happens at the copy, not later. The program can still run normally for a while after the copy, which is why the failure is quiet. The damage becomes visible only when one of the objects changes the shared resource, or when the objects clean up that resource. Until then, nothing in the code looks wrong.

The Vector class has a destructor, and this is a useful clue. 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. The practical lesson is that a class of this kind needs its copy behavior defined on purpose, rather than accepting whatever the default produces.