Copy Constructors and Copy Operations

Most people think of objects as things you can duplicate whenever you need a second one, and for many objects that instinct is fine. Some objects break that instinct. An object may be responsible for something valuable, such as a large collection of numbers or a running background activity. For these objects, duplication fails in one of two ways. Either duplicating the object is so expensive that it defeats the purpose, or duplicating it is simply not possible.

This article follows one question. When you need an object's contents to live in a different scope, how can the language give you that without duplicating the resource underneath? The technique that answers it is to relocate the object's resource to a new home instead of making a copy of it. That technique is called a move.

Before any detail about move operations, it helps to track a single question at each step: which object is responsible for the resource right now? Think of ownership as a single label that names the object currently responsible for the resource. Before a transfer, the label names the source object. The resource itself sits with that source.

Read the diagram carefully. The resource on the right is the same resource that was on the left. What changed is the label. The label moved from the source to the destination. The point of the change is that responsibility moves while the resource is not rebuilt. That is the core difference between a move and a copy, and the rest of this article builds on it.

The source names four kinds of member that together control a resource's lifetime: constructors, copy operations, move operations, and a destructor. Of these four, the move operations are the ones that let a resource change hands. Copy operations produce a second resource. Move operations take a resource that already exists and give it to another object. That is why moving is the tool to reach for when producing a second resource is unwanted.

The definition has two parts worth separating. The first part describes the result: an object moves from one scope to another, and the move is simple and cheap. The second part describes the purpose: the transfer is about ownership, so responsibility for the resource passes from one object to another. The word cheap is the key contrast with copying. A move does not need to build a fresh resource to match the old one.

A move constructor is the piece of a class that performs this handover when a new object is being created from an existing one. It changes the ownership label so that it names the destination. The source does not describe in detail what the source object is left holding after the handover. What it does establish is that responsibility for the resource has passed to the new object.

Copying and moving both get an object's contents into another scope, but they do it in different ways. A copy creates a separate resource for the new object. A move gives the existing resource to the new object. The source describes the move as simple and cheap, while copying is either impossible or undesirable for the objects it considers. That contrast is the reason move semantics exists.

The source gives two concrete cases that motivate the technique. In both, the goal is the same: get the object into the new scope without going through a copy.

The pattern in these two cases gives a practical test. Ask whether duplicating the object is impossible, or whether it is so expensive that it defeats the purpose. If either answer is yes, the object is a strong candidate for moving. The source's examples are objects that cannot be copied, such as a thread, and objects that should not be copied, such as a large Vector. Simple values are a different case, since the source does not present them as candidates for this technique.

Copying and moving are two ways of getting an object into a new scope. Copying builds a separate resource, while moving hands the existing resource to a new owner. Move constructors transfer ownership by changing which object is responsible for the resource, and they do this simply and cheaply. Threads and large collections are the main candidates, because one cannot be copied and the other should not be copied.