Copy and Move Operations

When you write a class, you decide what happens when an object is copied, moved, created, and destroyed. These operations are the special member functions of the class. Each time a value is passed around in a program, one of these operations may run, often without the programmer noticing. Copying and moving are the two operations this article focuses on, and they fit together with construction and destruction.

The central idea is that copying is not automatically correct for every type. A class author has to decide whether the default copying behavior suits the type, and if it does not, change it. That decision drives the rest of this article: prohibiting or redefining copying, returning containers by value, and designing the constructors and destructor as a set.

The special member functions of a class are the default constructor, the destructor, the copy constructor, the copy assignment operator, the move constructor, and the move assignment operator. These are the operations that control how an object is created, duplicated, transferred, and cleaned up.

A class may have several special member functions, and you do not always have to write their implementations yourself. The compiler can generate implementations as needed. The one important exception is the ordinary constructor: the compiler does not generate it for you. So a class that needs to be created in some specific way must have that constructor written by you.

A move operation is the mechanism for handing over the contents of an object instead of copying them in full. The source describes this for returned containers: the move operation is what allows the contents of the returned object to be handed to the caller efficiently, rather than copied. Think of a move as a change of ownership of a resource. The resource that was held by one object is now held by another, and the first object no longer has it.

Read the diagram from top to bottom. Before the move, the source object owns the heap resource and the destination has nothing. After the move, the resource belongs to the destination, and the source is left empty. Because the resource was transferred rather than duplicated, there is only one owner at any time. That single-owner outcome is what makes a move efficient, and it is also why the source object must be treated as having no resource after it has been moved from.

For pointer or reference members, the source asks you to consider copy and move behavior in light of ownership, and to document externally owned resources. A pointer member can mean two very different things. It can point to a resource that the class is responsible for releasing, or it can point to memory that some other part of the program owns. The right copy and move behavior depends on which of these is true.

The diagram shows what a default copy does to a pointer. The default copy duplicates the pointer value, not the thing it points to. In both groups, two objects now refer to one memory location. The question of what happens next depends on who is responsible for that memory. The two groups must be handled differently, as the next two subsections explain.

Default copying is the compiler's generated behavior for copy and move. It is appropriate when it gives the type the meaning its author intends. When it does not, the author must redefine the operation or prohibit copying altogether. The decision is not whether a class has a member function, but whether a needed special member function has been explicitly defined, and whether the default version is correct for this type.

Read the flowchart as a checklist for one class. Start with the members and any functions you have declared. If a destructor is declared, copy and move need review. If the class has pointer or reference members, decide who owns the referenced resource and document externally owned resources. Only when the default behavior matches what the type means can you let the compiler generate it. Otherwise you define the operation yourself or prohibit it.

Explicitly defining some default member functions prevents other default definitions from being generated. This is why you cannot treat each special member function as independent. Writing one of them changes what the compiler will supply for the others, so you must check the whole set after each change.

The practical consequence is that constructors, assignments, and the destructor should be designed as a matched set. These functions should agree about how an object is created, duplicated, transferred, and cleaned up. If one of them behaves differently from the others, the class becomes harder to reason about. When you define one, ask what the compiler will now generate for the rest, and whether those generated versions still match the design.

A function can return a container by value. Instead of forcing the caller to pass in an output object, the function builds its result and returns it. Returning by value relies on move operations for efficiency: the contents of the returned object are handed to the caller rather than copied in full. The source's advice is to return containers by value and rely on move for efficiency.

The complementary advice concerns inputs. When an operand is large, the source recommends using const reference argument types. A const reference lets a function read a large object without making its own copy of it. In short: return by value when moving is efficient, and accept large inputs by const reference so they are not copied on the way in.