您的位置：首页 > 编程语言 > C语言/C++

C++ Rvalue References Explained

2017-02-20 19:58 274 查看

Last updated: March 2013

Introduction
Move Semantics
Rvalue References
Forcing Move Semantics
Is an Rvalue Reference an Rvalue?
Move Semantics and Compiler Optimizations
Perfect Forwarding: The Problem
Perfect Forwarding: The Solution
Rvalue References and Exceptions
The Case of the Implicit Move
Acknowledgments and Further Reading

Introduction

Rvalue references are a feature of C++ that was added with the C++11 standard. What makes rvalue references a bit difficult to grasp is that when you first look at them, it is not clear what their purpose is or what problems they solve. Therefore, I will not
jump right in and explain what rvalue references are. Instead, I will start with the problems that are to be solved and then show how rvalue references provide the solution. That way, the definition of rvalue references will appear plausible and natural to
you.
Rvalue references solve at least two problems:

Implementing move semantics
Perfect forwarding

If you are not familiar with these problems, do not worry. Both of them will be explained in detail below. We'll start with move semantics. But before we're ready to go, I need to remind you of what lvalues and rvalues are in C++. Giving a rigorous definition
is surprisingly difficult, but the explanation below is good enough for the purpose at hand.
The original definition of lvalues and rvalues from the earliest days of C is as follows: An lvalue is an expression

that may appear on the left
or on the right hand side of an assignment, whereas anrvalue is an expression that can only appear on the right hand side of an assignment. For example,

int a = 42;
int b = 43;

// a and b are both l-values:
a = b; // ok
b = a; // ok
a = a * b; // ok

// a * b is an rvalue:
int c = a * b; // ok, rvalue on right hand side of assignment
a * b = 42; // error, rvalue on left hand side of assignment

In C++, this is still useful as a first, intuitive approach to lvalues and rvalues. However, C++ with its user-defined types has introduced some subtleties regarding modifiability and assignability that cause this definition to be incorrect. There is no
need for us to go further into this. Here is an alternate definition which, although it can still be argued with, will put you in a position to tackle rvalue references:An lvalue is an expression that
refers to a memory location and allows us to take the address of that memory location via the

operator. An rvalue is an expression that is not an lvalue. Examples are:

// lvalues:
//
int i = 42;
i = 43; // ok, i is an lvalue
int* p = &i; // ok, i is an lvalue
int& foo();
foo() = 42; // ok, foo() is an lvalue
int* p1 = &foo(); // ok, foo() is an lvalue

// rvalues:
//
int foobar();
int j = 0;
j = foobar(); // ok, foobar() is an rvalue
int* p2 = &foobar(); // error, cannot take the address of an rvalue
j = 42; // ok, 42 is an rvalue

If you are interested in a rigorous definition of rvalues and lvalues, a good place to start is Mikael Kilpeläinen's ACCU article on
the subject.

Move Semantics

Suppose

is a class that holds a pointer or handle to some resource, say,

m_pResource

. By a resource, I mean anything that takes considerable effort to construct,
clone, or destruct. A good example is

std::vector

, which holds a collection of objects that live in an array of allocated memory. Then, logically, the copy assignment operator for

looks like this:

X& X::operator=(X const & rhs)
{
// [...]
// Destruct the resource that m_pResource refers to.
// Make a clone of what rhs.m_pResource refers to, and
// attach it to m_pResource.
// [...]
}

Similar reasoning applies to the copy constructor. Now suppose

is used as follows:

X foo();
X x;
// perhaps use x in various ways
x = foo();

The last line above
destructs the resource held by

,
clones the resource from the temporary returned by

foo

,
destructs the temporary and thereby releases its resource.

Rather obviously, it would be ok, and much more efficient, to swap resource pointers (handles) between

and the temporary, and then let the temporary's destructor destruct

's original resource. In other words, in the special case
where the right hand side of the assignment is an rvalue, we want the copy assignment operator to act like this:

// [...]
// swap m_pResource and rhs.m_pResource
// [...]

This is called move semantics. With C++11, this conditional behavior can be achieved via an overload:

X& X::operator=(<mystery type> rhs)
{
// [...]
// swap this->m_pResource and rhs.m_pResource
// [...]
}

Since we're defining an overload of the copy assignment operator, our "mystery type" must essentially be a reference: we certainly want the right hand side to be passed to us by reference. Moreover, we expect the following behavior of the mystery type: when
there is a choice between two overloads where one is an ordinary reference and the other is the mystery type, then rvalues must prefer the mystery type, while lvalues must prefer the ordinary reference.

If you now substitute "rvalue reference" for "mystery type" in the above, you're essentially looking at the definition of rvalue references.

Rvalue References

is any type, then

X&&

is called an rvalue reference to

. For better distinction, the ordinary reference

X&

is now also called
an lvalue reference.
An rvalue reference is a type that behaves much like the ordinary reference

X&

, with several exceptions. The most important one is that when it comes to function overload resolution, lvalues prefer old-style lvalue references, whereas rvalues
prefer the new rvalue references:

void foo(X& x); // lvalue reference overload
void foo(X&& x); // rvalue reference overload

X x;
X foobar();

foo(x); // argument is lvalue: calls foo(X&)
foo(foobar()); // argument is rvalue: calls foo(X&&)

So the gist of it is:

Rvalue references allow a function to branch at compile time (via overload resolution) on the condition "Am I being called on an lvalue or an rvalue?"

It is true that you can overload any function in this manner, as shown above. But in the overwhelming majority of cases, this kind of overload should occur only for copy constructors
and assignment operators, for the purpose of achieving move semantics:

X& X::operator=(X const & rhs); // classical implementation
X& X::operator=(X&& rhs)
{
// Move semantics: exchange content between this and rhs
return *this;
}

Implementing an rvalue reference overload for the copy constructor is similar.

Caveat: As it happens so often in C++, what looks just right at first glance is still a little shy of perfect. It turns out that
in some cases, the simple exchange of content between

this

and

rhs

in the implementation of the copy assignment operator above is not quite good enough. We'll come back to this in Section 4, "Forcing Move Semantics" below.

Note: If you implement

void foo(X&);

but not

void foo(X&&);

then of course the behavior is unchanged:

foo

can be called on l-values, but not on r-values. If you implement

void foo(X const &);

but not

void foo(X&&);

then again, the behavior is unchanged:

foo

can be called on l-values and r-values, but it is not possible to make it distinguish between l-values and r-values. That is possible only by implementing

void foo(X&&);

as well. Finally, if you implement

void foo(X&&);

but neither one of

void foo(X&);

and

void foo(X const &);

then, according to the final version of C++11,

foo

can be called on r-values, but trying to call it on an l-value will trigger a compile error.

Forcing Move Semantics

As we all know, the First Amendment to the C++ Standard states: "The committee shall make no rule that prevents C++ programmers from shooting themselves in the foot." Speaking less
facetiously, when it comes to choosing between giving programmers more control and saving them from their own carelessness, C++ tends to err on the side of giving more control. Being true to that spirit, C++11 allows you to use move semantics not just on rvalues,
but, at your discretion, on lvalues as well. A good example is the std library function

swap

. As before, let X be a class for which we have overloaded the copy constructor and copy assignment operator to achieve move semantics on rvalues.

template<class T>
void swap(T& a, T& b)
{
T tmp(a);
a = b;
b = tmp;
}

X a, b;
swap(a, b);

There are no rvalues here. Hence, all three lines in

swap

use non-move semantics. But we know that move semantics would be fine: wherever a variable occurs as the source of a copy construction or assignment, that variable is either not used again
at all, or else it is used only as the target of an assignment.
In C++11, there is an std library function called

std::move

that comes to our rescue. It is a function that turns its argument into an rvalue without doing anything else. Therefore, in C++11, the std library function

swap

looks
like this:

template<class T>
void swap(T& a, T& b)
{
T tmp(std::move(a));
a = std::move(b);
b = std::move(tmp);
}

X a, b;
swap(a, b);

Now all three lines in

swap

use move semantics. Note that for those types that do not implement move semantics (that is, do not overload their copy constructor and assignment operator with an rvalue reference version), the new

swap

behaves
just like the old one.

std::move

is a very simple function. Unfortunately, though, I cannot show you the implementation yet. We'll come back to it later.

Using

std::move

wherever we can, as shown in the

swap

function above, gives us the following important benefits:

For those types that implement move semantics, many standard algorithms and operations will use move semantics and thus experience a potentially signifi
167c5
cant performance gain. An important example is inplace
sorting: inplace sorting algorithms do hardly anything else but swap elements, and this swapping will now take advantage of move semantics for all types that provide it.
The STL often requires copyability of certain types, e.g., types that can be used as container elements. Upon close inspection, it turns out that in many cases, moveability is enough. Therefore, we can now
use types that are moveable but not copyable (

unique_pointer

comes to mind) in many places where previously, they were not allowed. For example, these types can now be used as STL container elements.

Now that we know about

std::move

, we are in a position to see why the implementation
of the rvalue reference overload of the copy assignment operator that I showed earlier is still a bit problematic. Consider a simple assignment between variables, like this:

a = b;

What do you expect to happen here? You expect the object held by

to be replaced by a copy of

, and in the course of this replacement, you expect the object formerly held by

to be destructed. Now consider the line

a = std::move(b);

If move semantics are implemented as a simple swap, then the effect of this is that the objects held by

and

are being exchanged between

and

. Nothing is being destructed yet. The object formerly held
by

will of course be destructed eventually, namely, when

goes out of scope. Unless, of course,

becomes the target of a move, in which case the object formerly held by

gets passed on again.Therefore,
as far as the implementer of the copy assignment operator is concerned, it is not known when the object formerly held by

will be destructed.
So in a sense, we have drifted into the netherworld of non-deterministic destruction here: a variable has been assigned to, but the object formerly held by that variable is still out there somewhere. That's fine as long as the destruction of that object
does not have any side effects that are visible to the outside world. But sometimes destructors do have such side effects. An example would be the release of a lock inside a destructor.Therefore, any part of an
object's destruction that has side effects should be performed explicitly in the rvalue reference overload of the copy assignment operator:

X& X::operator=(X&& rhs)
{

// Perform a cleanup that takes care of at least those parts of the
// destructor that have side effects. Be sure to leave the object
// in a destructible and assignable state.

// Move semantics: exchange content between this and rhs

return *this;
}

Is an Rvalue Reference an Rvalue?

As before, let X be a class for which we have overloaded the copy constructor and copy assignment operator to implement move semantics. Now consider:

void foo(X&& x)
{
X anotherX = x;
// ...
}

The interesting question is: which overload of

's copy constructor gets called in the body of

foo

? Here,

is a variable that is declared as an rvalue reference, that is, a reference which preferably and typically (although
not necessarily!) refers to an rvalue. Therefore, it is quite plausible to expect that

itself should also bind like an rvalue, that is,

X(X&& rhs);

should be called. In other words, one might expect that anything that is declared as an rvalue reference is itself an rvalue. The designers of rvalue references have chosen a solution that is a bit more subtle than that:

Things that are declared as rvalue reference can be lvalues
or rvalues. The distinguishing criterion is: if it has a name, then it is an lvalue. Otherwise, it is an rvalue.

In the example above, the thing that is declared as an rvalue reference has a name, and therefore, it is an lvalue:

void foo(X&& x)
{
X anotherX = x; // calls X(X const & rhs)
}

Here is an example of something that is declared as an rvalue reference and does not have a name, and is therefore an rvalue:

X&& goo();
X x = goo(); // calls X(X&& rhs) because the thing on
// the right hand side has no name

And here's the rationale behind the design: Allowing move sematics to be applied tacitly to something that has a name, as in

X anotherX = x;
// x is still in scope!

would be dangerously confusing and error-prone because the thing from which we just moved, that is, the thing that we just pilfered, is still accessible on subsequent lines of code.
But the whole point of move semantics was to apply it only where it "doesn't matter," in the sense that the thing from which we move dies and goes away right after the moving. Hence the rule, "If it has a name, then it's an lvalue."
So then what about the other part, "If it does not have a name, then it's an rvalue?" Looking at the

goo

example above, it is technically possible, though not very likely, that the expression

goo()

in the second line of the example
refers to something that is still accessible after it has been moved from. But recall from the previous section: sometimes that's what we want! We want to be able to force move semantics on lvalues at our discretion, and it is precisely the rule, "If it does
not have a name, then it's an rvalue" that allows us to achieve that in a controlled manner. That's how the function

std::move

works. Although it is still too early to show you the exact implementation, we just got a step closer to understanding

std::move

.
It passes its argument right through by reference, doing nothing with it at all, and its result type is rvalue reference. So the expression

std::move(x)

is declared as an rvalue reference and does not have a name. Hence, it is an rvalue.Thus,

std::move

"turns its argument into an rvalue even if it isn't," and it achieves that by "hiding the name."
Here is an example that shows how important it is to be aware of the if-it-has-a-name rule.
Suppose you have written a class

Base

, and you have implemented move semantics by overloading

Base

's copy constructor and assignment operator:

Base(Base const & rhs); // non-move semantics
Base(Base&& rhs); // move semantics

Now you write a class

Derived

that is derived from

Base

. In order to assure that move semantics is applied to the

Base

part of your

Derived

objects, you must overload

Derived

's copy constructor
and assignment operator as well. Let's look at the copy constructor. The copy assignment operator is handled analogously. The version for lvalues is straightforward:

Derived(Derived const & rhs)
: Base(rhs)
{
// Derived-specific stuff
}

The version for rvalues has a big fat subtlety. Here's what someone who is not aware of the if-it-has-a-name
rule might have done:

Derived(Derived&& rhs)
: Base(rhs) // wrong: rhs is an lvalue
{
// Derived-specific stuff
}

If we were to code it like that, the non-moving version of

Base

's copy constructor would be called, because

rhs

, having a name, is an lvalue. What we want to be called is

Base

's moving copy constructor, and the way to
get that is to write

Derived(Derived&& rhs)
: Base(std::move(rhs)) // good, calls Base(Base&& rhs)
{
// Derived-specific stuff
}

Move Semantics and Compiler Optimizations

Consider the following function definition:

X foo()
{
X x;
// perhaps do something to x
return x;
}

Now suppose that as before, X is a class for which we have overloaded the copy constructor and copy assignment operator to implement move semantics. If you take the function definition above at face value, you may be tempted to say, wait a minute, there is
a value copy happening here from x to the location of

foo

's return value. Let me make sure we're using move semantics instead:

X foo()
{
X x;
// perhaps do something to x
return std::move(x); // making it worse!
}

Unfortunately, that would make things worse rather than better.
Any modern compiler will apply return value optimization to the original function definition. In other words, rather than constructing an

locally and then copying it out, the compiler would construct the

object directly
at the location of

foo

's return value. Rather obviously, that's even better than move semantics.

So as you can see, in order to really use rvalue references and move semantics in an optimal way, you need to fully understand and take into account today's compilers' "special effects" such asreturn value optimization
and copy elision. Dave Abrahams has written an excellent series of articles on this subject
on his blog. The details get pretty subtle, but hey, we chose C++ as our language of choice for a reason, right? We made our beds, so now let's lie in them.

Perfect Forwarding: The Problem

The other problem besides move semantics that rvalue references were designed to solve is the perfect forwarding problem. Consider the following simple factory function:

template<typename T, typename Arg>
shared_ptr<T> factory(Arg arg)
{
return shared_ptr<T>(new T(arg));
}

Obviously, the intent here is to forward the argument

arg

from the factory function to

's constructor. Ideally, as far as

arg

is concerned, everything should behave just as if the factory function weren't there and the
constructor were called directly in the client code: perfect forwarding.
The code above fails miserably at that: it introduces an extra call by value, which is particularly bad if the constructor takes its argument by reference.
The most common solution, chosen e.g. by

boost::bind

, is to let the outer function take the argument by reference:

template<typename T, typename Arg>
shared_ptr<T> factory(Arg& arg)
{
return shared_ptr<T>(new T(arg));
}

That's better, but not perfect. The problem is that now, the factory function cannot be called on rvalues:

factory<X>(hoo()); // error if hoo returns by value
factory<X>(41); // error

This can be fixed by providing an overload which takes its argument by const reference:

template<typename T, typename Arg>
shared_ptr<T> factory(Arg const & arg)
{
return shared_ptr<T>(new T(arg));
}

There are two problems with this approach. Firstly, if

factory

had not one, but several arguments, you would have to provide overloads for all combinations of non-const and const reference for the
various arguments. Thus, the solution scales extremely poorly to functions with several arguments.
Secondly, this kind of forwarding is less than perfect because it blocks out move semantics: the argument of the copy constructor of

in the body of

factory

is an lvalue. Therefore,
move semantics can never happen even if it would without the wrapping function.

It turns out that rvalue references can be used to solve both these problems. They make it possible to achieve truly perfect forwarding without the use of overloads. In order to understand how, we need to look at two more rules for rvalue references.

Perfect Forwarding: The Solution

The first of the remaining two rules for rvalue references affects old-style lvalue references as well. Recall that in pre-11 C++, it was not allowed to take a reference to a reference: something
like

A& &

would cause a compile error.
C++11, by contrast, introduces the following reference collapsing rules:

A& &

becomes

A&

A& &&

becomes

A&

A&& &

becomes

A&

A&& &&

becomes

A&&

Secondly, there is a special template argument deduction rule for function templates that take an argument by rvalue reference to a template argument:

template<typename T>
void foo(T&&);

Here, the following apply:
When foo is called on an lvalue of type

, then

resolves to

A&

and hence, by the reference collapsing rules above, the argument type effectively becomes

A&

.
When foo is called on an rvalue of type

, then

resolves to

, and hence the argument type becomes

A&&

.

Given these rules, we can now use rvalue references to solve the perfect forwarding problem as set forth in the previous
section. Here's what the solution looks like:

template<typename T, typename Arg>
shared_ptr<T> factory(Arg&& arg)
{
return shared_ptr<T>(new T(std::forward<Arg>(arg)));
}

where

std::forward

is defined as follows:

template<class S>
S&& forward(typename remove_reference<S>::type& a) noexcept
{
return static_cast<S&&>(a);
}

(Don't pay attention to the

noexcept

keyword for now. It lets the compiler know,
for certain optimization purposes, that this function will never throw an exception. We'll come back to it in Section
9.) To see how the code above achieves perfect forwarding, we will discuss separately what happens when our factory function gets called on lvalues and rvalues. Let

and

be types. Suppose first that

factory<A>

is
called on an lvalue of type

X x;
factory<A>(x);

Then, by the special template deduction rule stated above,

factory

's template argument

Arg

resolves to

X&

. Therefore, the compiler will create the following instantiations
of

factory

and

std::forward

shared_ptr<A> factory(X& && arg)
{
return shared_ptr<A>(new A(std::forward<X&>(arg)));
}

X& && forward(remove_reference<X&>::type& a) noexcept
{
return static_cast<X& &&>(a);
}

After evaluating the

remove_reference

and applying the reference collapsing rules, this becomes:

shared_ptr<A> factory(X& arg)
{
return shared_ptr<A>(new A(std::forward<X&>(arg)));
}

X& std::forward(X& a)
{
return static_cast<X&>(a);
}

This is certainly perfect forwarding for lvalues: the argument

arg

of the factory function gets passed on to

's constructor through two levels of indirection, both by old-fashioned lvalue reference.
Next, suppose that

factory<A>

is called on an rvalue of type

X foo();
factory<A>(foo());

Then, again by the special template deduction rule stated above,

factory

's template argument

Arg

resolves to

. Therefore, the compiler will now create the following
function template instantiations:

shared_ptr<A> factory(X&& arg)
{
return shared_ptr<A>(new A(std::forward<X>(arg)));
}

X&& forward(X& a) noexcept
{
return static_cast<X&&>(a);
}

This is indeed perfect forwarding for rvalues: the argument of the factory function gets passed on to

's constructor through two levels of indirection, both by reference. Moreover,

's constructor sees as its argument an expression
that is declared as an rvalue reference and does not have a name. By the no-name rule,
such a thing is an rvalue. Therefore,

's constructor gets called on an rvalue. This means that the forwarding preserves any move semantics that would have taken place if the factory wrapper were not present.
It is perhaps worth noting that the preservation of move semantics is in fact the only purpose of

std::forward

in this context. Without the use of

std::forward

, everything
would work quite nicely, except that

's constructor would always see as its argument something that has a name, and such a thing is an lvalue.Another way of putting this is to say that

std::forward

's
purpose is to forward the information whether at the call site, the wrapper saw an lvalue or an rvalue.

If you want to dig a little deeper for extra credit, ask yourself this question:why is the

remove_reference

in the definition of

std::forward

needed? The answer is, it is not really
needed at all. If you use just

S&

instead of

remove_reference<S>::type&

in the defintion of

std::forward

, you can repeat the case
distinction above to convince yourself that perfect forwarding still works just fine.However, it works fine only as long as we explicitly specify

Arg

as the template argument of

std::forward

.
The purpose of the

remove_reference

in the definition of

std::forward

is to force us to do so.

Rejoice. We're almost done. It only remains to look at the implementation of

std::move

. Remember, the purpose of

std::move

is to pass its argument right through by reference and make it bind like an rvalue. Here's the implementation:

template<class T>
typename remove_reference<T>::type&&
std::move(T&& a) noexcept
{
typedef typename remove_reference<T>::type&& RvalRef;
return static_cast<RvalRef>(a);
}

Suppose that we call

std::move

on an lvalue of type

X x;
std::move(x);

By the new special template deduction rule, the template argument

will resolve to

X&

. Therefore, what the compiler ends up instantiating is

typename remove_reference<X&>::type&&
std::move(X& && a) noexcept
{
typedef typename remove_reference<X&>::type&& RvalRef;
return static_cast<RvalRef>(a);
}

After evaluating the

remove_reference

and applying the new reference collapsing rules, this becomes

X&& std::move(X& a) noexcept
{
return static_cast<X&&>(a);
}

That does the job: our lvalue

will bind to the lvalue reference that is the argument type, and the function passes it right through, turning it into an unnamed rvalue reference.
I leave it to you to convince yourself that

std::move

actually works fine when called on an rvalue. But then you may want to skip that: why would anybody want to call

std::move

on an rvalue, when its only purpose is to turn things
into rvalues? Also, you have probably noticed by now that instead of

std::move(x);

you could just as well write

static_cast<X&&>(x);

However,

std::move

is strongly preferred because it is more expressive.

Rvalue References And Exceptions

Normally, when you develop software in C++, it is your choice whether you want to pay attention to exception safety, or to use exceptions at all in your code. Rvalue references are a bit different
in this regard. When you overload the copy constructor and the copy assignment operator of a class for the sake of move semantics, it is very much recommended that you do the following:
Strive to write your overloads in such a way that they cannot throw exceptions. That is often trivial, because move semantics typically do no more than exchange pointers and resource handles between two objects.
If you succeeded in not throwing exceptions from your overloads, then make sure to advertise that fact using the new

noexcept

keyword.
If you don't do both of these things, then there is at least one very common situation where your move semantics will not be applied despite the fact that you would very much expect it: when an

std::vector

gets
resized, you certainly want move semantics to happen when the existing elements of your vector are being relocated to the new memory block. But that won't happen unless both of 1. and 2. above are satisfied.

The reasons for this behavior are rather complex. For the full story, see Dave Abrahams' blog entry on
the subject. Note that the blog entry was written before the solution using

noexcept

was introduced. The blog entry describes the problem; to understand how

noexcept

is used to solve the problem, follow the link under "update #2"
at the top of the blog entry.

The Case of the Implicit Move

At one point during the (often complex and controversial) discussion of rvalue references, the Standard Committee decided that move constructors and move assignment operators, that is, rvalue
reference overloads for copy constructors and copy assignment operators, should be generated by the compiler when not provided by the user. This seems like a natural and plausible thing to request, considering that the compiler has always done the exact same
thing for ordinary copy constructors and copy assignment operators. In August of 2010, Scott Meyers posted
a message on comp.lang.c++ in which he explained how compiler-generated move constructors can break existing code in a rather serious way. Dave Abrahams has summarized the problem in this
blog entry.
The committee then decided that this was indeed cause for alarm, and it restricted the automatic generation of move constructors and move assignment operators in such a way that it is much less likely, though not impossible, for existing code to break. The
committee's decision is summarized in this blog post by Herb Sutter.

The issue of implicitly moving remained controversial all the way up to the finalization of the Standard (see e.g. this
blog post by Dave Abrahams and the ensuing discussion). In an ironic twist of fate, the only reason why the committee considered implicit move in the first place was as an attempt to resolve the issue with rvalue references and exceptions as mentioned
in Section 9.This problem was subsequently solved
in a more satisfactory way via the new

noexcept

keyword. Had the

noexcept

solution been found just a few months earlier, implicit move may have never seen the light of day. Oh well, so it goes.

Ok, that's it, the whole story on rvalue references. As you can see, the benefits are considerable. The details are gory. As a C++ professional, you will have to understand these details. Otherwise, you have given up on fully understanding the central tool
of your trade. You can take solace, though, in the thought that in your day-to-day programming, you will only have to remember three things about rvalue references:

By overloading a function like this:

void foo(X& x); // lvalue reference overload
void foo(X&& x); // rvalue reference overload

you can branch at compile time on the condition "is

foo

being called on an lvalue or an rvalue?"The primary (and for all practical purposes, the
only) application of that is to overload the copy constructor and copy assignment operator of a class for the sake of implementing move semantics. If and when you do that, make sure to pay attention to exception handling, and use the new

noexcept

keyword
as much as you can.

std::move

turns its argument into an rvalue.

std::forward

allows you to achieve perfect forwarding if you use it exactly as shown in the factory function example in Section
8.

Enjoy!

Acknowledgments and Further Reading

I am indebted to Thomas Witt for the insight and information on rvalue references that he shared with me. Thanks to Valentin David for reading the article carefully and providing valuable corrections
and insights. Many more readers have helped to improve the article. Thanks everybody for their contributions, and please do keep sending feedback. All remaining inaccuracies and deficiencies are mine.
I very much recommend reading the article by Howard E. Hinnant, Bjarne Stroustrup, and Bronek Kozicki on the subject
of C++ rvalue references at the C++ Source. This article has more and better examples than mine does, and it has an extensive list of links to proposals and technical papers which you will find interesting. As a tradeoff, the article does not go into all the
details the way I do; for example, it does not explicitly state the new reference collapsing rules or the special template argument deduction rule for rvalue references.

As mentioned earlier, Dave Abrahams' sequence of articles on value semantics on his blog explains
all the subtleties of how move semantics tie in with existing optimizations like return value optimization and copy elision. Another one of his blog entries explains the
way rvalue references interact with exception safety, and and how the new

noexcept

keyword makes everything work. Be sure to follow the link under "update #2" at the top of that blog entry. Finally, Dave Abrahams' blog also explains the problems
arising from implicit moves.

I also recommend Scott Meyers' 2012 article "Universal References in C++11," in which
he presents the "Grand Unification Theory" of references in C++.

From: http://thbecker.net/articles/rvalue_references/section_01.html

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航

C++ Rvalue References Explained

Contents

Introduction

Move Semantics

Rvalue References

Forcing Move Semantics

Is an Rvalue Reference an Rvalue?

Move Semantics and Compiler Optimizations

Perfect Forwarding: The Problem

Perfect Forwarding: The Solution

Rvalue References And Exceptions

The Case of the Implicit Move

Acknowledgments and Further Reading