Moving and Rvalue References
Last week, I said that the C++ type system helps the compiler figure out whether to move or copy an object. I'd like to continue by saying more about how it does so.
- Integration with Oracle Fusion Financials Cloud Service
- Application Performance Monitoring (APM) in the Age of Hybrid Cloud: Ten Key Findings by EMA
In general, C++ doesn't treat whether an expression is an lvalue as being part of its type. So, for example, if we define a variable:
then the type of
int. Moreover, the type of
3 is also
int. Nevertheless, it is not always possible to use
3 interchangeably, even if they have the same type. Although we can write
int& r = n;
we cannot write
int& s = 3;
because of the rule that says that when we define a reference, we must initialize it from an lvalue. In this case,
n is an lvalue and
3 is not; so we cannot use
3 to initialize
s. This rule makes it possible for compilers to catch errors such as
std::cin >> 3;
This call is equivalent to
In other words, it is calling a function named
operator>> that is a member of the object
std::cin, and giving that function
3 as an argument. That function, in turn, is overloaded, but although one of its overloaded versions has an
int& parameter, none of them has a plain
int parameter or a parameter of any type that will accept an
int rvalue argument. Therefore, the compiler will determine that it is not possible to call
operator>> with an
int rvalue as its argument.
C++11 extends the notion of references to include rvalue references. An rvalue reference is still a kind of reference, but unlike a plain reference, it can be bound only to an rvalue. We write an rvalue reference this way:
int&& t = 3;
A plain reference can be bound only to an lvalue; an rvalue reference can be bound only to an rvalue. So, for example, if we had written
int&& t = n; // Error: n is an lvalue
the compiler would reject it because
n is an lvalue.
An rvalue reference is an interesting kind of hybrid, because although you can bind it only to an rvalue, you use it as an lvalue. The point is that because you must have bound it to an rvalue, it is no longer possible to use that value outside your code. This fact means that you can clobber the rvalue as you wish, effectively treating it as an lvalue, and the rest of the program will not notice. For example:
int&& t = 3; ++t;
Ordinarily, a program can't change an rvalue. However, in this case, binding
t to the rvalue
3 essentially gave lvalue access to it. The program could clobber the value of
3 because no other part of the program is going to be able to access that particular instance of
3; so clobbering it is harmless. The knowledge that the rvalue will not be used again gets passed along as part of the "rvalue reference" property of variables, which, in turn, allows those variables to be moved instead of copied.
Defining a function to take an rvalue reference parameter allows that function to move its argument rather than copying it. However, it does so at the cost of prohibiting lvalue arguments:
void foo(int&&); foo(42); // OK; int n; foo(n); // Error: n is an lvalue
We can solve this problem by overloading the function:
void bar(int&&); void bar(const int&); bar(42); // calls bar(int&&) int n; bar(n); // calls bar(const int&)
This technique is worth remembering: by overloading a function with a reference to
const and an rvalue reference, you give the compiler the information it needs to tell your function when it is safe to modify its parameter and when it is not safe. Moreover, the compiler makes this safety decision during compilation, thereby avoiding any runtime overhead that might come along with it.
Next week, we'll start looking at just what a function has to do in order to move a value instead of copying it.