条款11： 在operator=中处理“自我赋值”

结论：

• 确保当对象自我赋值时operator=有良好行为。其中技术包括“来源对象”和“目标对象”的地址、精心周到的语句顺序以及copy-and-swap。

首先通过一个案例来引入
假设你简历一个class用来保存一个指向一块动态分配的位图(bitmap)：

class Bitmap {...};
class Widget
{
	...
private:
	Bitmap* pb;	// 指针，指向一个从heap分配而得的对象
}；

下面是operator=实现代码，表面上看起来合理，但是自我赋值时并不安全

Widget& Wideget::operator=(const Wideget& rhs) // 一份不安全的operator=实现版本
{
	delete pb;					// 停止使用当前的bitmap
	pb = new Bitmap(*rhs.pb);	// 使用rhs的bitmap的副本
	return *this;
}

问题：

1. 自我赋值中存在的问题是，operator=函数的*this（赋值的目的端）和rhs有可能是同一个对象，那么delete就不只是销毁当前对象的bitmap，它也销毁rhs的bitmap。在函数末尾，Widget发现自己持有一个指针指向已被删除的对象！
2. 不具备异常安全性。如果new Bitmap操作失败（可能是因为分配时内存不足或因为BItmap的copy构造函数抛出异常），Widget最终会持有一个指针指向一块被删除的Bitmap。这样的指针式有害的，你无法安全地删除它们，甚至无法安全地读取它们。

问题1的解决方案：证同测试

传统的做法是，operator=的实现最前面加一个“证同测试”达到“自我赋值”的检验目的：

Widget& Widget::operator=(const Widget& rhs)
{
	if (this == &rhs) return *this; // 证同测试，如果是自我赋值就不做任何事。
	delete pb;
	pb = new Bitmap(*rhs.pb);
	return *this;
}

问题2的解决方案

保证异常安全性，只需要注意在复制pb所指东西之前别删除pb。

Widget& Widget::operator=(const Widget& rhs)
{
	Bitmap* pOrig = pb;			// 记住原先的pb
	pb = new Bitmap(*rhs.pb);	// 令pb指向*pb的一个复件（副本）
	delete pOrig;				// 删除原先的pb
	return *this;
}

现在，如果“new Bitmap”抛出异常，pb保持原状。即使没有了证同测试，这段代码还是能够处理自我赋值，因为我们对bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。

替代方案：使用copy and swap技术。这个技术和"异常安全性"有密切关系。

class Widget
{
	...
	void swap(Widget& rhs);	// 交换*this和rhs的数据
	...
};
Widget& Widget::operator=(const Widget& rhs)
{
	Widget temp(rhs);	// 将rhs数据制作一份复件（副本）
	swap(temp);			// 讲*this数据和上述复件的数据交换
	return *this;
}

如果存在以下事实:(1) 某class的copy assignment操作符可能被声明为“以by value方式接受实参”； （2）以by value方式传递东西会造成一份复件/副本。

Widget& Widget::operator=(Widget rhs)		// rhs是被传对象的一份复件
{											// 注意这里是pass by value
	swap(rhs);								// 将*this的数据和复件数据互换
	retrun *this;
}

关于效率上一个值得思考的问题
如果很关心效率，可以把“证同测试”再次放回函数起始处。然而这样做之前先问问自己，你估计“自我赋值“发生的频率有多高？因为这项测试也需要成本。它会使代码变大一些（包括原始码和目标码）并蹈入新的控制流分支，而两者都会降低执行速度。