We can create overloads of a function based on whether they take lvalue expressions or rvalue expressions. In particular, we can overload the copy constructor to take rvalue expressions. For the TCPSocket class, we can write the following:

TCPSocket(const TCPSocket&) = delete;

TCPSocket(TCPSocket&& rvref) : socket_fd_(-1)
{
  std::swap(socket_fd_, rvref.socket_fd_);
}

While the lvalue overload is the deleted copy constructor, rvalue overload is called the move constructor because this is implemented to usurp or "steal" the contents of the rvalue expression passed to it. It moves the contents of the source to the target, leaving the source (rvref) in some unspecified state that is safe to destruct. In this case, this amounts to setting the socket_fd_ member of the rvref to -1.

With this definition of the move constructor, TCPSocket becomes movable but not copyable. The connectToService implementation would work correctly:

TCPSocket connectToService()
{
  return TCPSocket(get_service_host(),get_service_port());
}

This would move the temporary object back to the caller. But the following call to performIO would be ill-formed because socket is an lvalue expression and TCPSocket only defines move semantics for which an rvalue expression was necessary:

TCPSocket socket = connectToService();
performIO(socket);

This is a good thing because you cannot move contents out of an object like socket that you could potentially use later. An rvalue-expression of a movable type can be passed by value and thus the following will be well-formed:

performIO(connectToService());

Note that the expression connectToService()is an rvalue expression because it is not bound to a name and its address cannot be taken.

A type can be both copyable and movable. For example, we could implement a move constructor for the String class in addition to its copy constructor:

 1 // move-constructor
 2 String::String(String&& source) noexcept
 3       : buffer_(0), len_(0)
 4 {
 5   swap(source); // See listing A.1c
 6 }

The nothrow swap plays a central role in the implementation of move semantics. The contents of the source and target objects are exchanged. So when the source object goes out of scope in the calling scope, it releases its new contents (the target object's old state). The target object lives on with its new state (the source object's original state). The move is implemented in terms of the nothrow swap, which just swaps pointers and values of primitive types, and it is guaranteed to succeed; hence, the noexcept specification. In fact, moving objects usually requires less work involving swapping pointers and other data bits, while copying often requires new allocations that could potentially fail.

Just as we can construct an object by stealing the contents of another object, we can also move the contents of one object to another after both have been constructed. To do this, we can define a move assignment operator, an rvalue-overload of the copy assignment operator:

 1 // move assignment
 2 String& String::operator=(String&& rhs) noexcept
 3 {
 4   swap(rhs);
 5   return *this;
 6 }

Alternatively, we can define a universal assignment operator that works for both lvalue and rvalue expressions:

 1 // move assignment
 2 String& String::operator=(String rhs)
 3 {
 4   swap(rhs);
 5   return *this;
 6 }

Note that the universal assignment operator cannot coexist with either the lvalue or the rvalue overload, else there would be ambiguity in overload resolution.

When you call a function with an rvalue expression, the compiler resolves function calls to an rvalue-overload of the function if one is available. But if you call the function with a named variable, it gets resolved to an lvalue overload if one is available or the program is ill-formed. Now you might have a named variable that you can move from because you have no use for it later:

void performIO(TCPSocket socket);

TCPSocket socket = connectToService();
// do stuff on socket
performIO(socket);  // ill-formed because socket is lvalue

The preceding example will fail to compile because performIO takes its sole parameter by value and socket is of a move-only type but it is not an rvalue expression. By using std::move, you can cast an lvalue expression to an rvalue expression, and pass it to a function that expects an rvalue expression. The std::move function template is defined in the standard header utility.

#include <utility> // for std::moves
performIO(std::move(socket));

The call to std::move(socket) gives us an rvalue reference to socket; it does not cause any data to be moved out of socket. When we pass this expression of rvalue-reference type to the function performIO, which takes its parameter by value, a new TCPSocket object is created in the performIO function, corresponding to its by-value parameter. It is move initialized from socket, that is, its move constructor steals the contents of socket. Following the call to performIO, the variable socket loses its contents and therefore should not be used in further operations. If the move constructor of TCPSocket is correctly implemented, then socket should still be safe to destruct.

The expression std::move(socket) shares the identity of socket, but it would potentially be moved from within the function it is passed to. Such expressions are called xvalues, the x standing for expired.

If performIO did not take its parameter by value but as an rvalue-reference then one thing would change:

void performIO(TCPSocket&& socket);
performIO(std::move(socket));

The call to performIO(std::move(socket)) would still be well-formed, but would not automatically move out the contents of socket. This is because we pass a reference to an existing object here, whereas we create a new object that is move initialized from socket when we pass by value. In this case, unless the performIO function implementation explicitly moves out the contents of socket, it would still remain valid in the calling context after the call to performIO.

An object of type T that is local to a function can be returned by value from that function if T has an accessible move or copy constructor. If a move constructor is available, the returned value will be move-initialized, else it would be copy-initialized. If however, the object is not local to the function, then it must have an accessible copy constructor to be returned by value. Additionally, compilers, whenever they can, optimize away copies and moves.

Consider the implementation of connectToService and how it is used:

 1 TCPSocket connectToService()
 2 {
 3   return TCPSocket(get_service_host(),get_service_port());
 4 }
 5
 6 TCPSocket socket = connectToService();

In this case, the compiler will actually construct the temporary (line 3) directly in the storage for the socket object (line 6) where the return value of connectToService was meant to be moved to. This way, it would simply optimize away the move initialization of socket (line 6). This optimization is effected even if the move constructor has side effects, which means that those side effects may not take effect as a result of this optimization. In the same way, the compiler can optimize away copy initialization and directly construct the returned object at the target site. This is referred to as Return Value Optimization (RVO) and has been the norm for all major compilers since C++03, when it optimized away only copies. Although the copy or move constructors are not invoked when RVO takes effect, they must nevertheless be defined and accessible for RVO to work.

While RVO applies when rvalue expressions are returned, the compiler can sometimes optimize away a copy or move, even when a named local object on the stack is returned from a function. This is known as Named Return Value Optimization (NRVO).

Return Value Optimization is a specific case of Copy Elision, in which the compiler optimizes away a move or copy of an rvalue expression to construct it directly in the target storage:

std::string reverse(std::string input);

std::string a = "Hello";
std::string b = "World";
reverse(a + b);

In the preceding example, the expression a + b is an rvalue expression that generates a temporary object of type std::string. This object will not be copied into the function reverse instead the copy would be elided, and the object resulting from the expression a + b would be constructed directly in the storage for reverse's parameter.