Rvalue References and Move Semantics

Imagine a Vector class that owns a block of elements. Each time a Vector is handed from one place in a program to another, a naive design would duplicate it, and the program would pay for copying every element again and again. For a large Vector this cost can dominate the running time of the whole program.

Consider a function that builds a large result inside itself and then hands that result back to the caller. Copying every element of that result is wasted effort, because the function is finished with its local object the moment it returns. The question this article answers is whether the program can take the value directly from the temporary object and leave the temporary empty. C++ provides a mechanism for exactly this kind of transfer, and it starts with the double ampersand notation, &&.

The word rvalue is understood against its partner, lvalue. An lvalue is roughly something that can appear on the left-hand side of an assignment. An rvalue, to a first approximation, is a value you cannot assign to. An integer returned by a function call is a typical example: you can use it, store it, or pass it along, but you cannot assign to it the way you assign to a named variable.

The phrase steal its value is the heart of the idea, and stealing here does not mean wrongdoing. The receiving object takes over the contents of the temporary, because the temporary is about to disappear and no one else needs those contents. The program recognises that the value has no remaining owner who cares about it, so ownership can simply pass to the new holder.

The source gives a concrete case of this pattern: the local variable res inside the addition operator for a Vector class. That variable is built inside the function. At the moment it is returned, it is a value nobody else can assign to, so it is a natural candidate for having its value stolen rather than copied.

The rule is about how the value is being used at that point in the program, not merely about the type of the variable. The same object could be copied in one statement and moved in another, depending on whether the source is an rvalue at that moment.

A move constructor is a special constructor that takes an rvalue reference and transfers ownership of the object's resources to the object being constructed. Its parameter is written Vector&& a. The name a is the object whose resources are being taken. The sketch below shows only the parts this article discusses; a complete class contains other members that are not shown here.

Notice what the constructor does not do. It does not allocate new storage and does not loop over the elements to copy them. The source introduces this constructor as easy to define for Vector because the work is only 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 does not move in memory. What changes is which object's member refers to it and which object's count describes it.

A move constructor does not take a const argument. The reason follows from its purpose: a move constructor is supposed to remove the value from its argument. A const argument could not be modified, so the constructor could never empty it. A move assignment is defined in a similar way, so the same reasoning applies to it.

A move operation is applied when an rvalue reference is used as an initializer or as the right-hand side of an assignment. The trigger is a specific situation: an object is being initialised from an rvalue, or assigned from one. The move is not something you request by naming a function in the middle of an expression. It is selected because the value on the right is one that can be stolen.

The source gives an example from the chapter: the expression r = x + y + z. The compiler chooses the move constructor to transfer the return value out of each addition, so the intermediate Vector objects are moved rather than copied.

After a move, the source object is not discarded in an unusable condition. The source object will still be destroyed at the end of its scope, and its destructor must be able to run safely on whatever state the move has left. This is a firm requirement. The destructor runs on an emptied source, and that is safe because the source no longer claims the storage.

The source also sets a further expectation. Typically, assignment to a moved-from object should still be allowed. After its value has been taken, the object can be given a new value. The object is empty in the sense that its old value has gone, but it is still a working object that can be reused. It should not be relied on to hold a meaningful value until it is given one.