Copy Constructors and Copy Assignment

Imagine a Vector class that owns a block of elements. Every time a Vector is handed from one place in a program to another, a naive design would duplicate the whole block, so the program pays to copy every element again and again. The cost grows with the number of elements, even though the program only wanted the value to end up in a different place.

Move semantics addresses this problem. Instead of creating a duplicate, an object can hand over the resources it already holds. The move constructor is the special constructor that makes this possible: it builds a new object by taking over another object's resources. This article focuses on that constructor and on the rvalue reference that lets the compiler choose it.

A move constructor's parameter is written as Vector&& a. The double ampersand declares an rvalue reference. An rvalue reference is the kind of reference that binds to rvalues, which are the temporary or otherwise short-lived values a program produces while computing, such as the result of an expression that is about to be thrown away.

Because the move constructor's parameter is an rvalue reference, the compiler can select this constructor when it is given a value whose resources can be taken. The choice is made by the compiler based on what kind of value is being passed, so the programmer does not have to call the move constructor by name. The name of the parameter, a, is the object whose resources are being taken.

The source gives one clear case where this selection happens automatically: when a function returns a value, the compiler chooses the move constructor to transfer that return value out of the function. For this reason, an expression such as r = x + y + z moves Vector objects rather than copying them.

The following sketch shows the shape of a move constructor for a Vector that stores a pointer to its elements, elem, and a count, sz. The member types and the surrounding class are simplified here for illustration; the constructor's signature and its two body steps follow the description in the source.

Notice what the constructor does not do. It does not allocate new storage and does not loop over the elements to copy them. The cost of the operation is a fixed number of pointer and integer assignments, no matter how many elements the Vector holds. This is why the source describes the constructor as trivial to define for Vector: the work is bookkeeping about which object owns the storage.

Before the move, the source object a owns the element storage and records how many elements it holds. After the move, the storage belongs to the new object, and a is left in a deliberately empty state. The element buffer itself does not move in memory. What changes is which object's member refers to it and which object's count describes it. The diagram below shows this transfer using an illustrative example with three elements; the three-element count is chosen for the example and is not a value taken from the source.

Read the diagram as a question of ownership. The storage is the same block in both halves. Before the move, the arrow from a leads to it. After the move, the arrow comes from the new object, and a no longer points anywhere.

The source object is not destroyed by a move. It remains a valid object that the program can still refer to, but the source material says that its elem is set to nullptr and its sz is set to 0. After that, it holds no elements and must not be used as the owner of them. The state change happens in two steps, and the diagram below follows the source object through them.

A copy constructor builds a new object with its own copy of the resource, so both objects end up with separate storage. A move constructor builds the new object by reassigning the existing resource, so only one object owns it at a time. The diagram below sets the two operations side by side.

The contrast is about where the cost is paid. The copy path does work proportional to the number of elements. The move path does a fixed amount of bookkeeping. This is the reason the source treats move semantics as the answer to repeatedly duplicating a Vector as it moves through a program.