# Item 11: 在 operator= 中处理 assignment to self（自赋值）
作者：Scott Meyers
译者：fatalerror99 (iTePub's Nirvana)
发布：http://blog.csdn.net/fatalerror99/
当一个 object（对象）赋值给自己的时候就发生了一次 assignment to self（自赋值）：
```
class Widget { ... };
Widget w;
...
w = w; // assignment to self
```
这看起来很愚蠢，但它是合法的，所以应该确信客户会这样做。另外，assignment（赋值）也并不总是那么容易辨别。例如，
```
a = a[j]; // potential assignment to self
```
如果 i 和 j 有同样的值就是一个 assignment to self（自赋值），还有
```
*px = *py; // potential assignment to self
```
如果 px 和 py 碰巧指向同一个东西，这也是一个 assignment to self（自赋值）。这些不太明显的 assignments to self（自赋值）是由 aliasing（别名）（有不止一个方法引用一个 object（对象））造成的。通常，使用 references（引用）或者 pointers（指针）操作相同类型的多个 objects（对象）的代码需要考虑那些 objects（对象）可能相同的情况。实际上，如果两个 objects（对象）来自同一个 hierarchy（继承体系），甚至不需要公开声明，它们就是相同类型的，因为一个 base class（基类）的 reference（引用）或者 pointer（指针）也能够引向或者指向一个 derived class（派生类）类型的 object（对象）：
```
class Base { ... };
class Derived: public Base { ... };
void doSomething(const Base& rb, // rb and *pd might actually be
Derived* pd); // the same object
```
如果你遵循 Item 13 和 14 的建议，你应该总是使用 objects（对象）来管理 resources（资源），而且你应该确保那些 resource-managing objects（资源管理对象）被拷贝时行为良好。在这种情况下，你的 assignment operators（赋值运算符）在你没有考虑自赋值的时候可能也是 self-assignment-safe（自赋值安全）的。然而，如果你试图自己管理 resources（资源）（如果你正在写一个 resource-managing class（资源管理类），你当然必须这样做），你可能会落入在你用完一个 resource（资源）之前就已意外地将它释放的陷阱。例如，假设你创建了一个 class（类），它持有一个指向动态分配 bitmap（位图）的 raw pointer（裸指针）：
```
class Bitmap { ... };
class Widget {
...
private:
Bitmap *pb; // ptr to a heap-allocated object
};
```
下面是一个表面上看似合理 operator= 的实现，但如果出现 assignment to self（自赋值）则是不安全的。（它也不是 exception-safe（异常安全）的，但我们要过一会儿才会涉及到它。）
```
Widget&
Widget::operator=(const Widget& rhs) // unsafe impl. of operator=
{
delete pb; // stop using current bitmap
pb = new Bitmap(*rhs.pb); // start using a copy of rhs's bitmap
return *this; // see Item 10
}
```
这里的 self-assignment（自赋值）问题在 operator= 的内部，*this（赋值的目标）和 rhs 可能是同一个 object（对象）。如果它们是，则那个 delete 不仅会销毁 current object（当前对象）的 bitmap（位图），也会销毁 rhs 的 bitmap（位图）。在函数的结尾，Widget——通过 assignment to self（自赋值）应该没有变化——发现自己持有一个指向已删除 object（对象）的指针。
防止这个错误的传统方法是在 operator= 的开始处通过 identity test（一致性检测）来阻止 assignment to self（自赋值）：
```
Widget& Widget::operator=(const Widget& rhs)
{
if (this == &rhs) return *this; // identity test: if a self-assignment,
// do nothing
delete pb;
pb = new Bitmap(*rhs.pb);
return *this;
}
```
这个也能工作，但是我在前面提及那个 operator= 的早先版本不仅仅是 self-assignment-unsafe（自赋值不安全）的，它也是 exception-unsafe（异常不安全）的，而且这个版本还有异常上的麻烦。详细地说，如果 "new Bitmap" 表达式引发一个 exception（异常）（可能因为供分配的内存不足或者因为 Bitmap 的 copy constructor（拷贝构造函数）抛出一个异常），Widget 将以持有一个指向被删除的 Bitmap 的指针而告终。这样的指针是有毒的，你不能安全地删除它们。你甚至不能安全地读取它们。你对它们唯一能做的安全的事情大概就是花费大量的调试精力来断定它们起因于哪里。
幸亏，使 operator= exception-safe（异常安全）一般也同时弥补了它的 self-assignment-safe（自赋值安全）。这就导致了更加通用的处理 self-assignment（自赋值）问题的方法就是忽略它，而将焦点集中于达到 exception safety（异常安全）。Item 29 更加深入地探讨了 exception safety（异常安全），但是在本 Item 中，已经足以看出，在很多情况下，仔细地调整一下语句的顺序就可以得到 exception-safe（异常安全）（同时也是 self-assignment-safe（自赋值安全））的代码。例如，在这里，我们只要注意不要删除 pb，直到我们拷贝了它所指向的目标之后：
```
Widget& Widget::operator=(const Widget& rhs)
{
Bitmap *pOrig = pb; // remember original pb
pb = new Bitmap(*rhs.pb); // make pb point to a copy of *pb
delete pOrig; // delete the original pb
return *this;
}
```
现在，如果 "new Bitmap" 抛出一个 exception（异常），pb（以及它所在的 Widget）的遗迹没有被改变。甚至不需要 identity test（一致性检测），这里的代码也能处理 assignment to self（自赋值），因为我们做了一个原始 bitmap（位图）的拷贝，删除原始 bitmap（位图），然后指向我们作成的拷贝。这可能不是处理 self-assignment（自赋值）的最有效率的做法，但它能够工作。
如果你关心效率，你可以在函数开始处恢复 identity test（一致性检测）。然而，在这样做之前，先问一下自己，你认为 self-assignments（自赋值）发生的频率是多少，因为这个检测不是免费午餐。它将使代码（源代码和目标代码）有少量增大，而且它将在控制流中引入一个分支，这两点都会降低运行速度。例如，instruction prefetching（指令预读），caching（缓存）和 pipelining（流水线操作）的效力都将被降低。
另一个可选的手动排列 operator= 中语句顺序以确保实现是 exception- and self-assignment-safe（异常和自赋值安全）的方法是使用被称为 "copy and swap" 的技术。这一技术和 exception safety（异常安全）关系密切，所以将在 Item 29 中描述。然而，这是一个写 operator= 的足够通用的方法，值得一看，这样一个实现看起来通常就像下面这样：
```
class Widget {
...
void swap(Widget& rhs); // exchange *this's and rhs's data;
... // see Item 29 for details
};
Widget& Widget::operator=(const Widget& rhs)
{
Widget temp(rhs); // make a copy of rhs's data
swap(temp); // swap *this's data with the copy's
return *this;
}
```
在这个主题上的一个变种利用了如下事实：（1）一个 clsaa（类）的 copy assignment（拷贝赋值运算符）可以被声明为 take its argument by value（以传值方式取得它的参数）；（2）通过传值方式传递某些东西以做出它的一个 copy（拷贝）（参见 Item 20）：
```
Widget& Widget::operator=(Widget rhs) // rhs is a copy of the object
{ // passed in — note pass by val
swap(rhs); // swap *this's data with
// the copy's
return *this;
}
```
对我个人来说，我担心这个方法在灵活的祭坛上牺牲了清晰度，但是通过将拷贝操作从函数体中转移到参数的构造中，有时能使编译器产生更有效率的代码倒也是事实。
Things to Remember
* 当一个 object（对象）被赋值给自己的时候，确保 operator= 是行为良好的。技巧包括比较 source（源）和 target objects（目标对象）的地址，关注语句顺序，和 copy-and-swap。
* 如果两个或更多 objects（对象）相同，确保任何操作多于一个 object（对象）的函数行为正确。
- Preface（前言）
- Introduction（导言）
- Terminology（术语）
- Item 1: 将 C++ 视为 federation of languages（语言联合体）
- Item 2: 用 consts, enums 和 inlines 取代 #defines
- Item 3: 只要可能就用 const
- Item 4: 确保 objects（对象）在使用前被初始化
- Item 5: 了解 C++ 为你偷偷地加上和调用了什么函数
- Item 6: 如果你不想使用 compiler-generated functions（编译器生成函数），就明确拒绝
- Item 7: 在 polymorphic base classes（多态基类）中将 destructors（析构函数）声明为 virtual（虚拟）
- Item 8: 防止因为 exceptions（异常）而离开 destructors（析构函数）
- Item 9: 绝不要在 construction（构造）或 destruction（析构）期间调用 virtual functions（虚拟函数）
- Item 10: 让 assignment operators（赋值运算符）返回一个 reference to *this（引向 *this 的引用）
- Item 11: 在 operator= 中处理 assignment to self（自赋值）
- Item 12: 拷贝一个对象的所有组成部分
- Item 13: 使用对象管理资源
- Item 14: 谨慎考虑资源管理类的拷贝行为
- Item 15: 在资源管理类中准备访问裸资源（raw resources）
- Item 16: 使用相同形式的 new 和 delete
- Item 17: 在一个独立的语句中将 new 出来的对象存入智能指针
- Item 18: 使接口易于正确使用，而难以错误使用
- Item 19: 视类设计为类型设计
- Item 20: 用 pass-by-reference-to-const（传引用给 const）取代 pass-by-value（传值）
- Item 21: 当你必须返回一个对象时不要试图返回一个引用
- Item 22: 将数据成员声明为 private
- Item 23: 用非成员非友元函数取代成员函数
- Item 24: 当类型转换应该用于所有参数时，声明为非成员函数
- Item 25: 考虑支持不抛异常的 swap
- Item 26: 只要有可能就推迟变量定义
- Item 27: 将强制转型减到最少
- Item 28: 避免返回对象内部构件的“句柄”
- Item 29: 争取异常安全（exception-safe）的代码
- Item 30: 理解 inline 化的介入和排除
- Item 31: 最小化文件之间的编译依赖
- Item 32: 确保 public inheritance 模拟 "is-a"
- Item 33: 避免覆盖（hiding）“通过继承得到的名字”
- Item 34: 区分 inheritance of interface（接口继承）和 inheritance of implementation（实现继承）
- Item 35: 考虑可选的 virtual functions（虚拟函数）的替代方法
- Item 36: 绝不要重定义一个 inherited non-virtual function（通过继承得到的非虚拟函数）
- Item 37: 绝不要重定义一个函数的 inherited default parameter value（通过继承得到的缺省参数值）
- Item 38: 通过 composition（复合）模拟 "has-a"（有一个）或 "is-implemented-in-terms-of"（是根据……实现的）
- Item 39: 谨慎使用 private inheritance（私有继承）
- Item 40: 谨慎使用 multiple inheritance（多继承）
- Item 41: 理解 implicit interfaces（隐式接口）和 compile-time polymorphism（编译期多态）
- Item 42: 理解 typename 的两个含义
- Item 43: 了解如何访问 templatized base classes（模板化基类）中的名字
- Item 44: 从 templates（模板）中分离出 parameter-independent（参数无关）的代码
- Item 45: 用 member function templates（成员函数模板） 接受 "all compatible types"（“所有兼容类型”）
- Item 46: 需要 type conversions（类型转换）时在 templates（模板）内定义 non-member functions（非成员函数）
- Item 47: 为类型信息使用 traits classes（特征类）
- Item 48: 感受 template metaprogramming（模板元编程）
- Item 49: 了解 new-handler 的行为
- Item 50: 领会何时替换 new 和 delete 才有意义
- Item 51: 编写 new 和 delete 时要遵守惯例
- Item 52: 如果编写了 placement new，就要编写 placement delete
- 附录 A. 超越 Effective C++
- 附录 B. 第二和第三版之间的 Item 映射