“自我赋值”发生在对象被赋值给自己时:
class Widget {};
Widget w;
// ...
w = w; // 赋值给自己
这看起来有点愚蠢,但它合法,所以不要认定客户绝不会那么做。此外赋值动作并不总是那么可被一眼辨识出来,例如:
a[i] = a[j]; // 潜在的自我赋值
如果i和j有相同的值,这便是个自我赋值。再看:
*px = *py; // 潜在的自我赋值
如果px和py恰巧指向同一个东西,这也是自我赋值。
这些并不明显的自我赋值,是“别名”( aliasing)带来的结果:所谓“别名”就是“有一个以上的方法指称(指涉)某对象”。一般而言如果某段代码操作pointers或references而它们被用来“指向多个相同类型的对象”,就需考虑这些对象是否为同一个。实际上两个对象只要来自同一个继承体系,它们甚至不需声明为相同类型就可能造成“别名”,因为一个base class 的 reference或pointer可以指向一个derived class对象:
class Base {};
class Derived: public Base {};
void doSomething(const Base& rb, Derived* pd); // rb和*pd有可能其实是同一对象
如果遵循条款13和条款14的忠告,你会运用对象来管理资源,而且你可以确定所谓“资源管理对象”在copy发生时有正确的举措。这种情况下你的赋值操作符或许是“自我赋值安全的”( self-assignment-safe),不需要额外操心。然而如果你尝试自行管理资源(如果你打算写一个用于资源管理的class 就得这样做),可能会掉进“在停止使用资源之前意外释放了它”的陷阱。假设你建立一个class用来保存一个指针指向一块动态分配的位图( bitmap) :
class Bitmap {};
class Widget {
// ...
private:
Bitmap* pb; // 指针,指向一个从heap分配而得到的对象
};
下面是operator= 实现代码,表面上看起来合理,但自我赋值出现时并不安全(它也不具备异常安全性,但我们稍后才讨论这个主题)。
Widget&
Widget::operator=(const Widget& rhs) { // 一份不安全的operator=实现版本
delete pb; // 停止使用当前的bitmap
pb = new Bitmap(*rhs.pb);
return *this;
}
这里的自我赋值问题是,operator=函数内的*this(赋值的目的端)和rhs有可能是同一个对象。果真如此delete就不只是销毁当前对象的 bitmap,它也销毁rhs 的 bitmap。在函数末尾,widget——它原本不该被自我赋值动作改变的——发现自己持有一个指针指向一个已被删除的对象!
欲阻止这种错误,传统做法是藉由operator=最前面的一个“证同测试( identitytest)”达到“自我赋值”的检验目的:
Widget& Widget::operator=(const Widget& rhs) {
if (this == &rhs) {
return *this;
}
delete pb;
pb = new Bitmap(*rhs.pb);
return *this;
}
这样做行得通。稍早我曾经提过,前一版operator= 不仅不具备“自我赋值安全性”,也不具备“异常安全性”,这个新版本仍然存在异常方面的麻烦。更明确地说,如果"new Bitmap”导致异常(不论是因为分配时内存不足或因为Bitmap的copy构造函数抛出异常),widget最终会持有一个指针指向一块被删除的Bitmap。这样的指针有害。你无法安全地删除它们,甚至无法安全地读取它们。唯一能对它们做的安全事情是付出许多调试能量找出错误的起源。
令人高兴的是,让 operator=具备“异常安全性”往往自动获得“自我赋值安全”的回报。因此愈来愈多人对“自我赋值”的处理态度是倾向不去管它,把焦点放在实现“异常安全性”(exception safety)上。条款29深度探讨了异常安全性,本条款只要你注意“许多时候一群精心安排的语句就可以导出异常安全(以及自我赋值安全)的代码”,这就够了。例如以下代码,我们只需注意在复制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(及其栖身的那个widget)保持原状。即使没有证同测试(identity test),这段代码还是能够处理自我赋值,因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法,但它行得通。
学到了
如果你很关心效率,可以把“证同测试”(identity test)再次放回函数起始处。然而这样做之前先问问自己,你估计“自我赋值”的发生频率有多高?因为这项测试也需要成本。它会使代码变大一些(包括原始码和目标码)并导入一个新的控制流(control flow)分支,而两者都会降低执行速度。Prefetching、caching 和 pipelining等指令的效率都会因此降低。
在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;
}
这个主题的另一个变奏曲乃利用以下事实:(1)某 class的copy assignment操作符可能被声明为“以by value方式接受实参”;(2)以by value方式传递东西会造成一份复件/副本(见条款20):
Widget& Widget::operator=(Widget rhs) {
swap(rhs); // pass by value
return *this;
}
请记住