effective c++ item11在 operator= 中处理 assignment to self（自赋值）

正确方法一：

SampleClass& operator= (const SampleClass& s)
{
         if(this == &s) return *this; //可以删掉
         a = s.a;
         b = s.b;
         float* tmp = p; // 先保存了旧的指针
         p = new float(*s.p); // 再申请新的空间，如果申请失败，p仍然指向原有的地址空间
         delete tmp; // 能走到这里，说明申请空间是成功的，这时可以删掉旧的内容了
         return *this;
}

大致的思路是保存好旧的，再试着申请新的，若申请有问题，旧的还能保存。这里可以删掉第一句话，因为“让operator具备异常安全往往自动获得自我赋值安全的回报”。

还有一种思路，就是先用临时的指针申请新的空间并填充内容，没有问题后，再释放到本地指针所指向的空间，最后用本地指针指向这个临时指针，像这样：

正确方法二：

SampleClass& operator= (const SampleClass& s)
{
         if(this == &s) return *this; //可以删掉
         a = s.a;
         b = s.b;
         float* tmp = new float(*s.p); // 先使用临时指针申请空间并填充内容
         delete p; // 若能走到这一步，说明申请空间成功，就可以释放掉本地指针所指向的空间
         p = tmp; // 将本地指针指向临时指针
         return *this;
}

上述两种方法都是可行，但还要注意拷贝构造函数里面的代码与这段代码的重复性，试想一下，如果此时对类增加一个私有的指针变量，这里面的代码，还有拷贝构造函数里面类似的代码，都需要更新，有没有可以一劳永逸的办法？

本书给出了最终的解决方案：

正确方法三：

SampleClass& operator= (const SampleClass& s)
{
         SampleClass tmp(s);
         swap(*this, tmp);
         return *this;
}

这样把负担都交给了拷贝构造函数，使得代码的一致性能到保障。如果拷贝构造函数中出了问题，比如不能申请空间了，下面的swap函数就不会执行到，达到了保持本地变量不变的目的。

一种进一步优化的方案如下：

正确方法四：

SampleClass& operator= (const SampleClass s)
{
         swap(*this, s);
         return *this;
}

注意这里去掉了形参的引用，将申请临时变量的任务放在形参上了，可以达到优化代码的作用。

当一个 object（对象）赋值给自己的时候就发生了一次 assignment to self（自赋值）：

class Widget { ... };

Widget w;
...

w = w; // assignment to self

这看起来很愚蠢，但它是合法的，所以应该确信客户会这样做。另外，assignment（赋值）也并不总是那么容易辨别。例如，

a[i] = 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 acopy 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（对象）的函数行为正确。