条款11 在operator=中处理“自我赋值”
2015-02-05 20:50
267 查看
结论:
(1)确保当一个对象自我赋值的时候,operator= 行为良好。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及 copy-and-swap。 ·
(2)确定任何函数如果操作一个以上的对象,而其中多个对象是同一个对象时,其行为仍然正确。
自我赋值发生在对象被赋值给自己时,它合法,所以不要认定客户绝不会这么做。此外赋值动作不是那么简单能一眼辨识出来:
这些不太明显的自我赋值是由 aliasing(别名)(有不止一个方法引用一个对象)造成的。通常,使用引用或者指针操作相同类型的多个对象需要考虑那些对象可能相同的情况。实际上,如果两个对象来自同一个继承体系,甚至不需要声明为相同类型就可能造成别名,因为一个基类的引用或者指针可以指向一个派生类对象:
如果你试图自己管理资源(如果正在写一个资源管理类),你可能会落入用完一个资源之前就已意外地将它释放的陷阱。例如,假设你建立一个类用来保存一个指针指向一块动态分配的位图:
为了防止上述问题,传统做法是在 operator= 的开始处通过 identity test(证同测试)来达到“自我赋值”的目的:
幸亏,使 operator=具备“异常安全性”往往自动获得“自我赋值安全”。因而可以将焦点集中于达到异常安全性。本例中,我们只要注意复制pb所指东西之前别删除pb:
另一个确保异常和自我赋值安全的方法是使用被称为 "copy and swap" 的技术。这是一个写 operator= 的常见且够好的方法:
(1)确保当一个对象自我赋值的时候,operator= 行为良好。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及 copy-and-swap。 ·
(2)确定任何函数如果操作一个以上的对象,而其中多个对象是同一个对象时,其行为仍然正确。
自我赋值发生在对象被赋值给自己时,它合法,所以不要认定客户绝不会这么做。此外赋值动作不是那么简单能一眼辨识出来:
a[i] =a[j]; // 如果i==j *px = *py;// 如果px、py指向同一个东西
这些不太明显的自我赋值是由 aliasing(别名)(有不止一个方法引用一个对象)造成的。通常,使用引用或者指针操作相同类型的多个对象需要考虑那些对象可能相同的情况。实际上,如果两个对象来自同一个继承体系,甚至不需要声明为相同类型就可能造成别名,因为一个基类的引用或者指针可以指向一个派生类对象:
class Base { ... }; class Derived: public Base { ... }; void doSomething(const Base& rb, Derived* pd); // rb和*pd有可能其实是同一对象
如果你试图自己管理资源(如果正在写一个资源管理类),你可能会落入用完一个资源之前就已意外地将它释放的陷阱。例如,假设你建立一个类用来保存一个指针指向一块动态分配的位图:
class Bitmap { ... }; class Widget { ... private: Bitmap *pb; // 指向一个从heap分配而得的对象的指针 };下面是operator=实现代码,表面合理但自我复制出现时并不安全:
//一份不安全的operator=的实现版本 Widget& Widget::operator=(constWidget& rhs) { delete pb; pb = new Bitmap(*rhs.pb); return *this; } /* 这里的this(赋值的目标)和 rhs 可能是同一个对象。果真如此 delete 不仅会销毁当前对象的bitmap, 也会销毁 rhs 的 bitmap。在函数的结尾,Widget(原本不该被自我赋值动作改变的) 发现自己持有一个指向已删除对象的指针。 */
为了防止上述问题,传统做法是在 operator= 的开始处通过 identity test(证同测试)来达到“自我赋值”的目的:
Widget& Widget::operator=(constWidget& rhs) { if (this == &rhs) return *this; // 证同测试:如果是自我赋值,就不做任何事 delete pb; pb = new Bitmap(*rhs.pb); return *this; }证同测试那句语句可保证“自我赋值安全性”,但不具备“异常安全性”。更明确地说,如果 "new Bitmap" 表达式引发一个异常(可能因分配时内存不足或者因为 Bitmap 的 copy构造函数抛出异常),Widget 最后会持有一个指针指向一块被删除的Bitmap。这样的指针是不能安全地删除,不能安全地读取。
幸亏,使 operator=具备“异常安全性”往往自动获得“自我赋值安全”。因而可以将焦点集中于达到异常安全性。本例中,我们只要注意复制pb所指东西之前别删除pb:
Widget& Widget::operator=(constWidget& rhs) { Bitmap *pOrig = pb; // 记住原先的pb pb = new Bitmap(*rhs.pb); // 令pb指向*pb的一个副本 delete pOrig; // 删除原先的pb return*this; }现在,如果"new Bitmap"抛出一个异常,pb(以及它所在的 Widget)保持原状。即使没有证同测试,这里的代码也能处理 自我赋值,因为我们做了一个原始bitmap的拷贝,删除原始bitmap,然后指向我们作成的拷贝。这可能不是处理自我赋值的最有效率的做法,但它能够工作。
另一个确保异常和自我赋值安全的方法是使用被称为 "copy and swap" 的技术。这是一个写 operator= 的常见且够好的方法:
class Widget { ... void swap(Widget& rhs); // 交换*this和rhs数据 ... }; Widget& Widget::operator=(constWidget& rhs) { Widget temp(rhs); // 为rhs数据***一份副本 swap(temp); // 将*this数据和上述复件的数据交换 return *this; }以下的变种利用了如下事实:(1)一个类的 copy赋值操作符可以被声明为“以值传递方式接受实参”;(2)通过值传递方式传递会生成一份副本:
Widget& Widget::operator=(Widget rhs) { // rhs是被传对象的一份副本,注意这里是值传递,将*this的数据和副本数据互换 swap(rhs); return *this; }这个方法在灵活的祭坛上牺牲了清晰度,但是通过将拷贝操作从函数体中转移到函数参数构造阶段中,有时能使编译器产生更有效率的代码倒也是事实。
相关文章推荐
- 条款11:在operator= 中处理“自我赋值”
- 条款11 在operator=中处理“自我赋值“
- 条款11:在operator=处理自我赋值
- Effective C++ 条款10 令operator=返回一个reference to *this 条款11 在operator=中处理"自我赋值"
- effective c++条款11 在operator=中处理“自我赋值”
- 条款11: 在operator= 中处理"自我赋值"
- 条款11:在operator=中处理“自我赋值
- 【Effective c++】条款11:在operator=中处理“自我赋值”
- Effective C++_笔记_条款11_在operator=中处理“自我赋值”
- 条款11:在operator= 中处理“自我赋值”
- 条款11:在operator=中处理“自我赋值”(Handle assignment to self in operator=.)
- Effective C++:条款11:在operator= 中处理“自我赋值”。
- 总结条款:11在operator=中处理“自我赋值”
- 条款11:在operator=中处理“自我赋值”
- 条款11:在operator = 中处理“自我赋值”
- 条款11: 在operator= 中处理"自我赋值"
- 条款11:在operator=中处理“自我赋值”
- 《Effect C++》学习------条款11:在 operator= 中处理“自我赋值”
- 条款11:在operator=中处理“自我赋值”
- EC读书笔记系列之6:条款11 在operator=中处理自我赋值