C++0x标准出来很长时间了，引入了很多牛逼的特性[1]。其中一个便是右值引用，Thomas Becker的文章[2]很全面的介绍了这个特性，读后有如醍醐灌顶，翻译在此以便深入理解。
目录
- 概述
- move语义
- 右值引用
- 强制move语义
- 右值引用是右值吗？
- move语义与编译器优化
- 完美转发：问题
- 完美转发：解决方案
- Rvalue References And Exceptions
- The Case of the Implicit Move
- Acknowledgments and Further Reading
概述
右值引用是由C++0x标准引入c++的一个令人难以捉摸的特性。
右值引用恶心的地方在于，当你看到它的时候根本不知道它的存在有什么意义，它是用来解决什么问题的。所以我不会马上介绍什么是右值引用。更好的方式是从它将解决的问题入手，然后讲述右值引用是如何解决这些问题的。这样，右值引用的定义才会看起来合理和自然。
右值引用至少解决了这两个问题：
- 实现move语义
- 完美转发(Perfect forwarding)
如果你不懂这两个问题，别担心，后面会详细地介绍。我们会从move语义开始，但在开始之前要首先让你回忆起c++的左值和右值是什么。关于左值和右值我很难给出一个严密的定义，不过下面的解释已经足以让你明白什么是左值和右值。
在c语言发展的较早时期，左值和右值的定义是这样的：左值是一个可以出现在赋值运算符的左边或者右边的表达式e，而右值则是只能出现在右边的表达式。例如：
1 int a = 42; 2 int b = 43; 3 4 // a与b都是左值 5 a = b; // ok 6 b = a; // ok 7 a = a * b; // ok 8 9 // a * b是右值: 10 int c = a * b; // ok, 右值在等号右边 11 a * b = 42; // 错误，右值在等号左边
在c++中，我们仍然可以用这个直观的办法来区分左值和右值。不过，c++中的用户自定义类型引入了关于可变性和可赋值性的微妙变化，这会让这个方法变的不那么地正确。我们没有必要继续深究下去，这里还有另外一种定义可以让你很好的处理关于右值的问题：左值是一个指向某内存空间的表达式，并且我们可以用&操作符获得该内存空间的地址。右值就是非左值的表达式。例如：
1 // 左值: 2 // 3 int i = 42; 4 i = 43; // ok, i是左值 5 int* p = &i; // ok, i是左值 6 int& foo(); 7 foo() = 42; // ok, foo()是左值 8 int* p1 = &foo(); // ok, foo()是左值 9 10 // 右值: 11 // 12 int foobar(); 13 int j = 0; 14 j = foobar(); // ok, foobar()是右值 15 int* p2 = &foobar(); // 错误，不能取右值的地址 16 j = 42; // ok, 42是右值
如果你对左值和右值的严密的定义有兴趣的话，可以看下Mikael Kilpeläinen的文章[3]。
move语义
假设class X包含一个指向某资源的指针或句柄m_pResource。这里的资源指的是任何需要耗费一定的时间去构造、复制和销毁的东西，比如说以动态数组的形式管理一系列的元素的std::vector。逻辑上而言X的赋值操作符应该像下面这样：
1 X& X::operator=(X const & rhs) 2 { 3 // [...] 4 // 销毁m_pResource指向的资源 5 // 复制rhs.m_pResource所指的资源，并使m_pResource指向它 6 // [...] 7 }
同样X的拷贝构造函数也是这样。假设我们这样来用X：
1 X foo(); // foo是一个返回值为X的函数 2 X x; 3 x = foo();
最后一行有如下的操作：
- 销毁x所持有的资源
- 复制foo返回的临时对象所拥有的资源
- 销毁临时对象，释放其资源
上面的过程是可行的，但是更有效率的办法是直接交换x和临时对象中的资源指针，然后让临时对象的析构函数去销毁x原来拥有的资源。换句话说，当赋值操作符的右边是右值的时候，我们希望赋值操作符被定义成下面这样：
1 // [...] 2 // swap m_pResource and rhs.m_pResource 3 // [...]
这就是所谓的move语义。在之前的c++中，这样的行为是很难实现的。虽然我也听到有的人说他们可以用模版元编程来实现，但是我还从来没有遇到过能给我解释清楚如何具体实现的人。所以这一定是相当复杂的。C++0x通过重载的办法来实现：
1 X& X::operator=(<mystery type> rhs) 2 { 3 // [...] 4 // swap this->m_pResource and rhs.m_pResource 5 // [...] 6 }
既然我们是要重载赋值运算符，那么<mystery type>肯定是引用类型。另外我们希望<mystery type>具有这样的行为：现在有两种重载，一种参数是普通的引用，另一种参数是<mystery type>，那么当参数是个右值时就会选择<mystery type>，当参数是左值是还是选择普通的引用类型。
把上面的<mystery type>换成右值引用，我们终于看到了右值引用的定义。
右值引用
如果X是一种类型，那么X&&就叫做X的右值引用。为了更好的区分两，普通引用现在被称为左值引用。
右值引用和左值引用的行为差不多，但是有几点不同，最重要的就是函数重载时左值使用左值引用的版本，右值使用右值引用的版本：
1 void foo(X& x); // 左值引用重载 2 void foo(X&& x); // 右值引用重载 3 4 X x; 5 X foobar(); 6 7 foo(x); // 参数是左值，调用foo(X&) 8 foo(foobar()); // 参数是右值，调用foo(X&&)
重点在于：
右值引用允许函数在编译期根据参数是左值还是右值来建立分支。
理论上确实可以用这种方式重载任何函数，但是绝大多数情况下这样的重载只出现在拷贝构造函数和赋值运算符中，以用来实现move语义：
1 X& X::operator=(X const & rhs); // classical implementation 2 X& X::operator=(X&& rhs) 3 { 4 // Move semantics: exchange content between this and rhs 5 return *this; 6 }
实现针对右值引用重载的拷贝构造函数与上面类似。
如果你实现了void foo(X&);，但是没有实现void foo(X&&);，那么和以前一样foo的参数只能是左值。如果实现了void foo(X const &);，但是没有实现void foo(X&&);，仍和以前一样，foo的参数既可以是左值也可以是右值。唯一能够区分左值和右值的办法就是实现void foo(X&&);。最后，如果只实现了实现void foo(X&&);，但却没有实现void foo(X&);和void foo(X const &);，那么foo的参数将只能是右值。
强制move语义
c++的第一版修正案里有这样一句话：“C++标准委员会不应该制定一条阻止程序员拿起枪朝自己的脚丫子开火的规则。”严肃点说就是c++应该给程序员更多控制的权利，而不是擅自纠正他们的疏忽。于是，按照这种思想，C++0x中既可以在右值上使用move语义，也可以在左值上使用，标准程序库中的函数swap就是一个很好的例子。这里假设X就是前面我们已经重载右值引用以实现move语义的那个类。
1 template<class T> 2 void swap(T& a, T& b) 3 { 4 T tmp(a); 5 a = b; 6 b = tmp; 7 } 8 9 X a, b; 10 swap(a, b);
上面的代码中没有右值，所以没有使用move语义。但move语义用在这里最合适不过了：当一个变量（a）作为拷贝构造函数或者赋值的来源时，这个变量要么就是以后都不会再使用，要么就是作为赋值操作的目标（a = b）。
C++11中的标准库函数std::move可以解决我们的问题。这个函数只会做一件事：把它的参数转换为一个右值并且返回。C++11中的swap函数是这样的:
1 template<class T> 2 void swap(T& a, T& b) 3 { 4 T tmp(std::move(a)); 5 a = std::move(b); 6 b = std::move(tmp); 7 } 8 9 X a, b; 10 swap(a, b);
现在的swap使用了move语义。值得注意的是对那些没有实现move语义的类型来说（没有针对右值引用重载拷贝构造函数和赋值操作符），新的swap仍然和旧的一样。
std::move是个很简单的函数，不过现在我还不能将它的实现展现给你，后面再详细说明。
像上面的swap函数一样，尽可能的使用std::move会给我们带来以下好处:
- 对那些实现了move语义的类型来说，许多标准库算法和操作会得到很大的性能上的提升。例如就地排序：就地排序算法基本上只是在交换容器内的对象，借助move语义的实现，交换操作会快很多。
- stl通常对某种类型的可复制性有一定的要求，比如要放入容器的类型。其实仔细研究下，大多数情况下只要有可移动性就足够了。所以我们可以在一些之前不可复制的类型不被允许的情况下，用一些不可复制但是可以移动的类型（unique_ptr）。这样的类型是可以作为容器元素的。
右值引用是右值吗？
假设有以下代码：
1 void foo(X&& x) 2 { 3 X anotherX = x; 4 // ... 5 }
现在考虑一个有趣的问题：在foo函数内，哪个版本的X拷贝构造函数会被调用呢？这里的x是右值引用类型。把x也当作右值来处理看起来貌似是正确的，也就是调用这个拷贝构造函数：
1 X(X&& rhs);
有些人可能会认为一个右值引用本身就是右值。但右值引用的设计者们采用了一个更微妙的标准：
1 右值引用类型既可以被当作左值也可以被当作右值，判断的标准是，如果它有名字，那就是左值，否则就是右值。
在上面的例子中，因为右值引用x是有名字的，所以x被当作左值来处理。
1 void foo(X&& x) 2 { 3 X anotherX = x; // 调用X(X const & rhs) 4 }
下面是一个没有名字的右值引用被当作右值处理的例子：
1 X&& goo(); 2 X x = goo(); // 调用X(X&& rhs)，goo的返回值没有名字
之所以采用这样的判断方法，是因为：如果允许悄悄地把move语义应用到有名字的东西（比如foo中的x）上面，代码会变得容易出错和让人迷惑。
1 void foo(X&& x) 2 { 3 X anotherX = x; 4 // x仍然在作用域内 5 }
这里的x仍然是可以被后面的代码所访问到的，如果把x作为右值看待，那么经过X anotherX = x;后，x的内容已经发生变化。move语义的重点在于将其应用于那些不重要的东西上面，那些move之后会马上销毁而不会被再次用到的东西上面。所以就有了上面的准则：如果有名字，那么它就是左值。
那另外一半，“如果没有名字，那它就是右值”又如何理解呢？上面goo()的例子中，理论上来说goo()所引用的对象也可能在X x = goo();后被访问的到。但是回想一下，这种行为不正是我们想要的吗？我们也想随心所欲的在左值上面使用move语义。正是“如果没有名字，那它就是右值”的规则让我们能够实现强制move语义。其实这就是std::move的原理。这里展示std::move的具体实现还是太早了点，不过我们离理解std::move更近了一步。它什么都没做，只是把它的参数通过右值引用的形式传递下去。
std::move(x)的类型是右值引用，而且它也没有名字，所以它是个右值。因此std::move(x)正是通过隐藏名字的方式把它的参数变为右值。
下面这个例子将展示记住“如果它有名字”的规则是多么重要。假设你写了一个类Base，并且通过重载拷贝构造函数和赋值操作符实现了move语义：
1 Base(Base const & rhs); // non-move semantics 2 Base(Base&& rhs); // move semantics
然后又写了一个继承自Base的类Derived。为了保证Derived对象中的Base部分能够正确实现move语义，必须也重载Derived类的拷贝构造函数和赋值操作符。先让我们看下拷贝构造函数（赋值操作符的实现类似），左值版本的拷贝构造函数很直白：
1 Derived(Derived const & rhs) 2 : Base(rhs) 3 { 4 // Derived-specific stuff 5 }
但右值版本的重载却要仔细研究下，下面是某个不知道“如果它有名字”规则的程序员写的：
1 Derived(Derived&& rhs) 2 : Base(rhs) // 错误：rhs是个左值 3 { 4 // ... 5 }
如果像上面这样写，调用的永远是Base的非move语义的拷贝构造函数。因为rhs有名字，所以它是个左值。但我们想要调用的却是move语义的拷贝构造函数，所以应该这么写：
1 Derived(Derived&& rhs) 2 : Base(std::move(rhs)) // good, calls Base(Base&& rhs) 3 { 4 // Derived-specific stuff 5 }
move语义与编译器优化
现在有这么一个函数：
1 X foo() 2 { 3 X x; 4 // perhaps do something to x 5 return x; 6 }
一看到这个函数，你可能会说，咦，这个函数里有一个复制的动作，不如让它使用move语义：
1 X foo() 2 { 3 X x; 4 // perhaps do something to x 5 return std::move(x); // making it worse! 6 }
很不幸的是，这样不但没有帮助反而会让它变的更糟。现在的编译器基本上都会做返回值优化（return value optimization）。也就是说，编译器会在函数返回的地方直接创建对象，而不是在函数中创建后再复制出来。很明显，这比move语义还要好一点。
所以，为了更好的使用右值引用和move语义，你得很好的理解现在编译器的一些特殊效果，比如return value optimization和copy elision。并且在运用右值引用和move语义时将其考虑在内。Dave Abrahams就这一主题写了一系列的文章[4]。
完美转发：问题
除了实现move语义之外，右值引用要解决的另一个问题就是完美转发问题（perfect forwarding）。假设有下面这样一个工厂函数：
1 template<typename T, typename Arg> 2 shared_ptr<T> factory(Arg arg) 3 { 4 return shared_ptr<T>(new T(arg)); 5 }
很明显，这个函数的意图是想把参数arg转发给T的构造函数。对参数arg而言，理想的情况是好像factory函数不存在一样，直接调用构造函数，这就是所谓的“完美转发”。但真实情况是这个函数是错误的，因为它引入了额外的通过值的函数调用，这将不适用于那些以引用为参数的构造函数。
最常见的解决方法，比如被boost::bind采用的，就是让外面的函数以引用作为参数。
1 template<typename T, typename Arg> 2 shared_ptr<T> factory(Arg& arg) 3 { 4 return shared_ptr<T>(new T(arg)); 5 }
这样确实会好一点，但不是完美的。现在的问题是这个函数不能接受右值作为参数：
1 factory<X>(hoo()); // error if hoo returns by value 2 factory<X>(41); // error
这个问题可以通过一个接受const引用的重载解决：
1 template<typename T, typename Arg> 2 shared_ptr<T> factory(Arg const & arg) 3 { 4 return shared_ptr<T>(new T(arg)); 5 }
这个办法仍然有两个问题。首先如果factory函数的参数不是一个而是多个，那就需要针对每个参数都要写const引用和non-const引用的重载。代码会变的出奇的长。
其次这种办法也称不上是完美转发，因为它不能实现move语义。factory内的构造函数的参数是个左值（因为它有名字），所以即使构造函数本身已经支持，factory也无法实现move语义。
右值引用可以很好的解决上面这些问题。它使得不通过重载而实现真正的完美转发成为可能。为了弄清楚是如何实现的，我们还需要再掌握两个右值引用的规则。
完美转发：解决方案
第一条右值引用的规则也会影响到左值引用。回想一下，在c++11标准之前，是不允许出现对某个引用的引用的：像A& &这样的语句会导致编译错误。不同的是，在c++11标准里面引入了引用叠加规则：
1 A& & => A& 2 A& && => A& 3 A&& & => A& 4 A&& && => A&&
另外一个是模版参数推导规则。这里的模版是接受一个右值引用作为模版参数的函数模版。
1 template<typename T> 2 void foo(T&&);
针对这样的模版有如下的规则：
- 当函数foo的实参是一个A类型的左值时，T的类型是A&。再根据引用叠加规则判断，最后参数的实际类型是A&。
- 当foo的实参是一个A类型的右值时，T的类型是A。根据引用叠加规则可以判断，最后的类型是A&&。
有了上面这些规则，我们可以用右值引用来解决前面的完美转发问题。下面是解决的办法：
1 template<typename T, typename Arg> 2 shared_ptr<T> factory(Arg&& arg) 3 { 4 return shared_ptr<T>(new T(std::forward<Arg>(arg))); 5 }
std::forward的定义如下：
1 template<class S> 2 S&& forward(typename remove_reference<S>::type& a) noexcept 3 { 4 return static_cast<S&&>(a); 5 }
上面的程序是如何解决完美转发的问题的？我们需要讨论当factory的参数是左值或右值这两种情况。假设A和X是两种类型。先来看factory的参数是X类型的左值时的情况：
1 X x; 2 factory<A>(x);
根据上面的规则可以推导得到，factory的模版参数Arg变成了X&，于是编译器会像下面这样将模版实例化：
1 shared_ptr<A> factory(X& && arg) 2 { 3 return shared_ptr<A>(new A(std::forward<X&>(arg))); 4 } 5 6 X& && forward(remove_reference<X&>::type& a) noexcept 7 { 8 return static_cast<X& &&>(a); 9 }
应用前面的引用叠加规则并且求得remove_reference的值后，上面的代码又变成了这样：
1 shared_ptr<A> factory(X& arg) 2 { 3 return shared_ptr<A>(new A(std::forward<X&>(arg))); 4 } 5 6 X& std::forward(X& a) 7 { 8 return static_cast<X&>(a); 9 }
这对于左值来说当然是完美转发：通过两次中转，参数arg被传递给了A的构造函数，这两次中转都是通过左值引用完成的。
现在再考虑参数是右值的情况：
1 X foo(); 2 factory<A>(foo());
再次根据上面的规则推导得到：
1 shared_ptr<A> factory(X&& arg) 2 { 3 return shared_ptr<A>(new A(std::forward<X>(arg))); 4 } 5 6 X&& forward(X& a) noexcept 7 { 8 return static_cast<X&&>(a); 9 }
对右值来说，这也是完美转发：参数通过两次中转被传递给A的构造函数。另外对A的构造函数来说，它的参数是个被声明为右值引用类型的表达式，并且它还没有名字。那么根据第5节中的规则可以判断，它就是个右值。这意味着这样的转发完好的保留了move语义，就像factory函数并不存在一样。
事实上std::forward的真正目的在于保留move语义。如果没有std::forward，一切都是正常的，但有一点除外：A的构造函数的参数是有名字的，那这个参数就只能是个左值。
如果你想再深入挖掘一点的话，不妨问下自己这个问题：为什么需要remove_reference？答案是其实根本不需要。如果把remove_reference<S>::type&换成S&，一样可以得出和上面相同的结论。但是这一切的前提是我们指定Arg作为std::forward的模版参数。remove_reference存在的原因就是强迫我们去这样做。
已经讲的差不多了，剩下的就是std::move的实现了。记住，std::move的用意在于将它的参数传递下去，将它转换成右值。
1 template<class T> 2 typename remove_reference<T>::type&& 3 std::move(T&& a) noexcept 4 { 5 typedef typename remove_reference<T>::type&& RvalRef; 6 return static_cast<RvalRef>(a); 7 }
下面假设我们针对一个X类型的左值调用std::move。
1 X x; 2 std::move(x);
根据前面的模版参数推导规则，模版参数T变成了X&，于是：
1 typename remove_reference<X&>::type&& 2 std::move(X& && a) noexcept 3 { 4 typedef typename remove_reference<X&>::type&& RvalRef; 5 return static_cast<RvalRef>(a); 6 }
然后求得remove_reference的值，并应用引用叠加规则，得到：
1 X&& std::move(X& a) noexcept 2 { 3 return static_cast<X&&>(a); 4 }
这就可以了，x变成了没有名字的右值引用。
参数是右值的情况由你来自己推导。不过你可能马上就想跳过去了，为什么会有人把std::move用在右值上呢？它的功能不就是把参数变成右值么。另外你可能也注意到了，我们完全可以用static_cast<X&&>(x)来代替std::move(x)，不过大多数情况下还是用std::move(x)比较好。
