本文为第四部分，目录请参阅概述部分：http://www.cnblogs.com/harrywong/p/4220233.html。
强制Move语义
众所周知，正如C++标准的第一修正案所陈述：“委员会不会建立任何试图绊住C++程序员的脚的规则。（The committee shall make no rule that prevents C++ programmers from shooting themselves in the foot.）”，正经来说，就是当面临给予程序员更多控制还是减少他们粗心大意机会的选择时，C++更倾向于及时可能导致犯错，但是依然给予更多控制。正是基于这种精神，C++11允许你使用Move语义而不仅仅局限于是右值，而是还有左值，这都给与你充分的决定权。一个好的例子就是标准库里面的swap方法。同以前一样，给出一个类X，基于它我们可以重载拷贝构造函数和拷贝赋值操作符来在右值上面实现Move语义。
template<class T> void swap(T& a, T& b) { T tmp(a); a = b; b = tmp; } X a, b; swap(a, b);
这里并没有右值。所以，在swap函数中的三行没有使用move语义。但是我们知道使用move语义是可行的：任何时候当一个变量作为源头出现在一个拷贝构造函数或者赋值语句的时候，那个变量将不会再被使用，或者仅仅被作为赋值的目标。
在C++11中，标准库中有一个叫做std::move的方法用来处理这种情况。这个函数只是将他的参数变成右值。因此，在C++11中，标准库函数swap将会像如下所示：
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);
现在所有在swap函数中的三行都使用了move语义。记住对于没有实现move语义的类型（也就是说，并没有为右值单独重载一个拷贝构造函数和赋值表达式的类型），新的swap行为表现同旧的版本是一致的。
std::move是一个非常简单的函数。不幸的是，尽管如此，我还不能将它的实现展现给你。我们将会在后面讨论它。
在任何能使用std::move的地方使用它。如上面的swap函数所示，它给我们带来如下好处：
- 对于实现了move语义的类型而言，需要标准库算法和操作将会使用move语义，然后因此得到潜在的性能提升。一个重要的例子就是原地排序（inplace sorting）：原地排序算法就是单纯的交换元素，其他什么都不做，然后现在交换的过程将会在提供了move语义的类型中，充分利用到move语义提供的优势。
- 标准模板库（STL）经常需要有些类型提供拷贝能力（copyability）。例如可以被用做容器元素的类型。通过严格的观察，事实证明，在很多情况下，移动能力（moveability）就足够了。因此，我们现在可以在某些以前并不被允许的地方使用可移动的而不是可复制的类型了（譬如
unique_pointer）。举例来说，这些类型现在可以被使用做标准模板库的容器类型了。
既然我们知道了std::move，我就就需要知道为什么实现一个基于右值引用的拷贝赋值表达式的重载，如同前面我所展示的，依然是有些问题的。考虑一个简单的变量间的赋值，像这样：
a = b;
你期待在这里发生什么？你期待被a持有的对象被一份b的拷贝所替代，当然在整个交换过程中，你期待原来被a持有的对象会被析构。现在考虑这行代码：
a = std::move(b);
如果move语义被实现为一个简单的交换，那么这里的表现就将会是被a和b持有的对象将在a和b间交换。没有任何东西被析构。当然原来被a持有的对象将会最终被析构，也就是说，当b离开了该代码的范围时。当然，除非b成为move的对象，在这种情况下，原来被a持有的对象又再次得到了一次。因此，只有拷贝赋值表达式的实现被精心考虑过后，我们并不知道原来被a持有的对象何时将被析构。
所以在某种意义上，我们在这里将会陷入到不确定性的泥沼中：一个变量被分配后，但是原来被该变量持有的对象却还在其他位置。只有那个对象的析构函数并不会对外面有任何副作用的时候才是可行的。但是某些时候，析构函数确实会有这种副作用。一个例子就是在析构函数中释放一个锁。因此，析构函数中任何可能含有副作用的部分应该在拷贝赋值操作符的右值引用重载中清晰地表现出来：
X& X::operator=(X&& rhs) { // 执行一次清理，要注意到那些在析构函数中可能产生副作用的地方。 // 确保对象处于可析构的和可赋值的状态 // Move语义，交换this和rhs的内容 return *this; }