“自我赋值”发生在对象被赋值给自己时:
class Widget {...};
Widget w;
...
w = w; //赋值给自己
这看起来有点愚蠢,但它合法,所以不要认定客户绝不会那么做。此外赋值动作并不总是那么可被一眼辨识出来,例如:
a[i] = a[j]; //潜在的自我赋值
如果i和j有相同的值,这便是自我赋值。再看:
*px = *py; //潜在的自我赋值
如果px和py恰巧指向同一个东西,这也是自我赋值。
自我赋值有可能会掉进“在停止使用资源之前以外释放了它”的陷阱。假设你建立一个class用来保存一个指针指向一块动态分配的位图(bitmap):
class Bitmap {...};
class Widget {
...
private:
Bitmap* bp;
};
下面是operator=实现代码,表面上看起来合理,但自我赋值出现时并不安全(它也不具备异常安全性,但我们稍后才讨论这个主题)。
Widget& Widget::operator=(const Widget& rhs)
{
delete pb;
pb = new Bitmap(*rhs.pb);
return *this;
}
这里的自我赋值问题是,operator=函数内的*this(赋值的目的端)和rhs有可能是同一个对象。果真如此delete就不只是销毁当前对象的bitmap,它也销毁rhs的bitmap。在函数末尾,Widget——它原本就不该被自我赋值动作改变的——发现自己持有一个指针指向一个已被删除的对象!
欲阻止这种错误,传统做法是藉由operator=最前面的一个“证同测试(identity test)”达到“自我赋值”的检测目的:
Widget& Widget::operator=(const Widget& rhs)
{
if (this == &rhs) return *this; //证同测试:如果是自我赋值,就不做任何事。
delete pb;
pb = new Bitmap(*rhs.pb);
return *this;
}
这样做行得通。但是如果“new Bitmap”导致异常(不论是因为分配时内存不足或因为Bitmap的copy构造函数抛出异常),Widget最终会持有一个指针指向一块被删除的Bitmap。
解决方法:
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(及其栖身的那个Widget)保持原状。即使没有证同测试,这段代码还是能够处理自我赋值,因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法,但它行得通。
在operator=函数内手工排列语句(确保代码不但“异常安全”而且“自我赋值安全”)的一个替代方案是,使用所谓的copy and swap技术。这个技术和“异常安全性”有密切关系,所有由条款29详细说明。然而由于它是一个常见而够好的operator=撰写办法,所以值得看看其实现手法像什么样子:
class Widget {
...
void swap(Widget& rhs); // 交换*this和rhs的数据;详见条款29
...
};
Widget& Widget::operator=(const Widget& rhs)
{
Widget temp(rhs); // 为rhs数据制作一份副本
swap(temp); // 将*this数据和上述附件的数据交换。
return *this;
}
请记住
-
确保当前对象自我赋值时operator=有良好的行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。
-
确定任何函数如果操作一个以上的对象,而其中多个对象是同一个对象时,其行为仍然正确。