链接：https://www.zhihu.com/question/22111546/answer/30801982
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
右值引用是C++11中最重要的新特性之一，它解决了C++中大量的历史遗留问题，使C++标准库的实现在多种场景下消除了不必要的额外开销（如std::vector, std::string)，也使得另外一些标准库（如std::unique_ptr, std::function）成为可能。即使你并不直接使用右值引用，也可以通过标准库，间接从这一新特性中受益。为了更好的理解标准库结合右值引用带来的优化，我们有必要了解一下右值引用的重大意义。
右值引用的意义通常解释为两大作用：移动语义和完美转发。本文主要讨论移动语义。
移动语义
======
移动语义，简单来说解决的是各种情形下对象的资源所有权转移的问题。而在C++11之前，移动语义的缺失是C++饱受诟病的问题之一。
举个栗子。
问题一：如何将大象放入冰箱？
答案是众所周知的。首先你需要有一台特殊的冰箱，这台冰箱是为了装下大象而制造的。你打开冰箱门，将大象放入冰箱，然后关上冰箱门。
问题二：如何将大象从一台冰箱转移到另一台冰箱？
普通解答：打开冰箱门，取出大象，关上冰箱门，打开另一台冰箱门，放进大象，关上冰箱门。
2B解答：在第二个冰箱中启动量子复制系统，克隆一只完全相同的大象，然后启动高能激光将第一个冰箱内的大象气化消失。
等等，这个2B解答听起来很耳熟，这不就是C++中要移动一个对象时所做的事情吗？
“移动”，这是一个三岁小孩都明白的概念。将大象（资源）从一台冰箱（对象）移动到另一台冰箱，这个行为是如此自然，没有任何人会采用先复制大象，再销毁大象这样匪夷所思的方法。C++通过拷贝构造函数和拷贝赋值操作符为类设计了拷贝/复制的概念，但为了实现对资源的移动操作，调用者必须使用先复制、再析构的方式。否则，就需要自己实现移动资源的接口。
为了实现移动语义，首先需要解决的问题是，如何标识对象的资源是可以被移动的呢？这种机制必须以一种最低开销的方式实现，并且对所有的类都有效。C++的设计者们注意到，大多数情况下，右值所包含的对象都是可以安全的被移动的。
右值（相对应的还有左值）是从C语言设计时就有的概念，但因为其如此基础，也是一个最常被忽略的概念。不严格的来说，左值对应变量的存储位置，而右值对应变量的值本身。C++中右值可以被赋值给左值或者绑定到引用。类的右值是一个临时对象，如果没有被绑定到引用，在表达式结束时就会被废弃。于是我们可以在右值被废弃之前，移走它的资源进行废物利用，从而避免无意义的复制。被移走资源的右值在废弃时已经成为空壳，析构的开销也会降低。
右值中的数据可以被安全移走这一特性使得右值被用来表达移动语义。以同类型的右值构造对象时，需要以引用形式传入参数。右值引用顾名思义专门用来引用右值，左值引用和右值引用可以被分别重载，这样确保左值和右值分别调用到拷贝和移动的两种语义实现。对于左值，如果我们明确放弃对其资源的所有权，则可以通过std::move()来将其转为右值引用。std::move()实际上是static_cast<T&&>()的简单封装。
右值引用至少可以解决以下场景中的移动语义缺失问题：
- 按值传入参数
class People {
public:
People(string name) // 按值传入字符串，可接收左值、右值。接收左值时为复制，接收右值时为移动
: name_(move(name)) // 显式移动构造，将传入的字符串移入成员变量
{
}
string name_;
};
People a("Alice"); // 移动构造name
string bn = "Bob";
People b(bn); // 拷贝构造name
构造a时，调用了一次字符串的构造函数和一次字符串的移动构造函数。如果使用const string& name接收参数，那么会有一次构造函数和一次拷贝构造，以及一次non-trivial的析构。尽管看起来很蛋疼，尽管编译器还有优化，但从语义来说按值传入参数是最优的方式。
如果你要在构造函数中接收std::shared_ptr<X>并且存入类的成员（这是非常常见的），那么按值传入更是不二选择。拷贝std::shared_ptr<X>需要线程同步，相比之下移动std::shared_ptr是非常轻松愉快的。
- 按值返回
void str_split(const string& s, vector<string>* vec); // 一个按值语义定义的字符串拆分函数。这里不考虑分隔符，假定分隔符是固定的。
这样要求vec在外部被事先构造，此时尚无从得知vec的大小。即使函数内部有办法预测vec的大小，因为函数并不负责构造vec，很可能仍需要resize。
对这样的函数嵌套调用更是痛苦的事情，谁用谁知道啊。
vector<string> str_split(const string& s) {
vector<string> v;
// ...
return v; // v是左值，但优先移动，不支持移动时仍可复制。
}
如果函数按值返回，return语句又直接返回了一个栈上的左值对象（输入参数除外）时，标准要求优先调用移动构造函数，如果不符再调用拷贝构造函数。尽管v是左值，仍然会优先采用移动语义，返回vector<string>从此变得云淡风轻。此外，无论移动或是拷贝，可能的情况下仍然适用编译器优化，但语义不受影响。
对于std::unique_ptr来说，这简直就是福音。unique_ptr<SomeObj> create_obj(/*...*/) {
unique_ptr<SomeObj> ptr(new SomeObj(/*...*/));
ptr->foo(); // 一些可能的初始化
return ptr;
}
unique_ptr<SomeObj> create_obj(/*...*/) {
return unique_ptr<SomeObj>(new SomeObj(/*...*/));
}
在工厂类中，这样的语义是非常常见的。返回unique_ptr能够明确对所构造对象的所有权转移，特别的，这样的工厂类返回值可以被忽略而不会造成内存泄露。上面两种形式分别返回栈上的左值和右值，但都适用移动语义（unique_ptr不支持拷贝）。
- 接收右值表达式
vector<string> str_split(const string& s);
vector<string> v = str_split("1,2,3"); // 返回的vector用以拷贝构造对象v。为v申请堆内存，复制数据，然后析构临时对象（释放堆内存）。
vector<string> v2;
v2 = str_split("1,2,3"); // 返回的vector被复制给对象v（拷贝赋值操作符）。需要先清理v2中原有数据，将临时对象中的数据复制给v2，然后析构临时对象。
注：v的拷贝构造调用有可能被优化掉，尽管如此在语义上仍然是有一次拷贝操作。
同样的代码，在支持移动语义的世界里就变得更美好了。vector<string> str_split(const string& s);
vector<string> v = str_split("1,2,3"); // 返回的vector用以移动构造对象v。v直接取走临时对象的堆上内存，无需新申请。之后临时对象成为空壳，不再拥有任何资源，析构时也无需释放堆内存。
vector<string> v2;
v2 = str_split("1,2,3"); // 返回的vector被移动给对象v（移动赋值操作符）。先释放v2原有数据，然后直接从返回值中取走数据，然后返回值被析构。
注：v的移动构造调用有可能被优化掉，尽管如此在语义上仍然是有一次移动操作。
不用多说也知道上面的形式是多么常用和自然。而且这里完全没有任何对右值引用的显式使用，性能提升却默默的实现了。
- 对象存入容器
void push_back( const T& value ); // (1)
void push_back( T&& value ); // (2)
不用多说自然是左值调用1右值调用2。如果你要往容器内放入超大对象，那么版本2自然是不2选择。
vector<vector<string>> vv;
vector<string> v = {"123", "456"};
v.push_back("789"); // 临时构造的string类型右值被移动进容器v
vv.push_back(move(v)); // 显式将v移动进vv
困扰多年的难言之隐是不是一洗了之了？
- std::vector的增长
又一个隐蔽的优化。当vector的存储容量需要增长时，通常会重新申请一块内存，并把原来的内容一个个复制过去并删除。对，复制并删除，改用移动就够了。
对于像vector<string>这样的容器，如果频繁插入造成存储容量不可避免的增长时，移动语义可以带来悄无声息而且美好的优化。
- std::unique_ptr放入容器
曾经，由于vector增长时会复制对象，像std::unique_ptr这样不可复制的对象是无法放入容器的。但实际上vector并不复制对象，而只是“移动”对象。所以随着移动语义的引入，std::unique_ptr放入std::vector成为理所当然的事情。
容器中存储std::unique_ptr有太多好处。想必每个人都写过这样的代码：MyObj::MyObj() {
for (...) {
vec.push_back(new T());
}
// ...
}
MyObj::~MyObj() {
for (vector<T*>::iterator iter = vec.begin(); iter != vec.end(); ++iter) {
if (*iter) delete *iter;
}
// ...
}
繁琐暂且不说，异常安全也是大问题。使用vector<unique_ptr<T>>，完全无需显式析构，unqiue_ptr自会打理一切。完全不用写析构函数的感觉，你造吗？
unique_ptr是非常轻量的封装，存储空间等价于裸指针，但安全性强了一个世纪。实际中需要共享所有权的对象（指针）是比较少的，但需要转移所有权是非常常见的情况。auto_ptr的失败就在于其转移所有权的繁琐操作。unique_ptr配合移动语义即可轻松解决所有权传递的问题。
注：如果真的需要共享所有权，那么基于引用计数的shared_ptr是一个好的选择。shared_ptr同样可以移动。由于不需要线程同步，移动shared_ptr比复制更轻量。
- std::thread的传递
thread也是一种典型的不可复制的资源，但可以通过移动来传递所有权。同样std::future std::promise std::packaged_task等等这一票多线程类都是不可复制的，也都可以用移动的方式传递。
完美转发
======
除了移动语义，右值引用还解决了C++03中引用语法无法转发右值的问题，实现了完美转发，才使得std::function能有一个优雅的实现。这部分不再展开了。
总结
======
一句话答案：右值引用的出现是为了实现移动语义，顺便解决完美转发的问题，其意义在于扩充了值语义，帮助Modern C++可以全面地应用RAII。
以下展开:
------------------------
- 澄清误区
在具体回答右值引用的价值之前，我想先否定题主的两个提法。
首先是"将这样一个问题留给程序员解决"
右值引用并没有将什么“问题”留给程序员解决，而是向程序员提供更多的选择。正如Bjarne Stroustrup所说，
"C++的许多设计决策根源于我对强迫人按某种特定方式行事的极度厌恶。"
"当我试图去取缔一个我不喜欢的语言特征时，我总抑制住这样的欲望，因为我认为我无权把个人观点强加给别人。"
选择是自主权的表现，向往自由的人一定不会认为有选择是件坏事。
更何况右值引用的神奇之处在于，在很多时候，使用函数库的程序员根本不用关心它的存在。例如：auto vec = init_data(args);
auto pi = make_shared<int>(11);
auto ei = resolver.resolve({"localhost", "1024"});
另一个是
"一种缺乏GC机制的语言为了性能的必要折衷"
由于有RAII的存在，C++通常是不需要GC的，因为RAII能让C++代码同时具备简洁、高性能(在某些特定的高并发环境里GC性能可能更高)和异常安全这三个特点。所以，C++暂时还不需要任何特性来作这种所谓的折衷。
- 为什么会觉得右值引用很怪？
根本原因是不理解值语义(Value Semantics)。
值语义是很多OO语言里没有的概念。在这些语言里，几乎所有的变量都是引用语义(Reference Semantics)，GC掌管了所有对象的生命期管理事务， 程序员无需为此操心，只需要用变量去对象池中去引用即可。值语义虽然也有出场的机会，例如Java里的Primitive Data Type，但毕竟不是重点，所以往往被忽视。
还有一个很重要的原因，在OO语言里，值语义和运行时多态是矛盾的。
值语义因此也成为了C++区别于其它OO语言的特征之一。
所以，在不理解值语义的情况下去谈右值引用，最多也是浅尝辄止，所以"感觉奇怪"也是很正常的，甚至会出现类似“C++的数组不支持多态”？这样的问题。
- 值语义的作用
首先给出一篇blog作为值语义的科普，内容则不再复述，以下只讨论其意义。
这篇blog的作者Andrzej Krzemieński，曾在另一篇blog中盛赞RAII，并认为它是C++'s best feature，Herb Sutter也在文章的回复中提到:RAII code is just naturally exception-safe with immediate cleanup, not leaking stuff until the GC gets around to finding it. This is especially important with scarce resources like file handles.
但问题是，像C#的using statement和Java的try-with-resources statement同样具有RAII的特点，但仍然有人会提出"RAII: Why is unique to C++?"这样的问题。原因即在于C++独有的值语义：程序员通过值语义可以方便直观地控制对象生命期，让RAII用起来更自然。
更何况像这段代码，vector<ifstream> produce()
{
vector<ifstream> ans;
for (int i = 0; i < 10; ++i) {
ans.emplace_back(name(i));
}
return ans;
}
void consumer()
{
vector<ifstream> files = produce();
for (ifstream& f: files) {
read(f);
}
}
用try-with-resources根本就搞不定。当然，finally还是可以搞定，只是代码会很丑。
所以，值语义在C++里的作用之一就是用于控制对象生命期(另一个作用就是提升性能)，以方便通过RAII写出简洁自然、异常安全的代码。该意义非常重大，这也是右值引用在C++ - State of the Evolution上稳坐头把交椅的原因。
- 右值引用与值语义
前面提到，值语义用于控制对象的生命期，而其具体的控制方式分为两种：
- 生命期限于scope内：无需控制，到期自动调用析构函数。
- 需要延长到scope外：移动语义。
因为右值引用的目的在于实现移动语义，所以右值引用 意义即是加强了值语义对对象生命期的控制能力。
在移动语义的作用下，Effective C++ 条款23从此作古：当你必须传回object时，不要尝试传回reference。
资源管理类，如std::ifstream、boost::asio::basic_stream_socket，可以光明正大地当成int来用，而无需担心类似Effective STL 条款8那样的问题：
切勿创建包含auto_ptr的容器对象。
- 右值引用与完美转发
右值引用还有一个作用是实现完美转发。完美转发可以在一定程度上让代码保持简洁，但同时，这也引入了一些令人讨厌的坑。个人感觉意义不如移动语义的重大，所以这里不再展开了。
---------------附参考资料
- C++ future and the pointer. Jens Weller
- Back to the Basics! Essentials of Modern C++ Style. Herb Sutter
- Move Constructor. Andrzej Krzemieński
- A proposal to Add Move Semantics Support to C++ Language. Howard E. Hinnant, Peter Dimov, Dave Abrahams
- C++ 工程实践(8)：值语义. 陈硕