Effective C++ 学习笔记 条款11 在operator=中处理“自我赋值”

“自我赋值”发生在对象被赋值给自己时：

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);    // 使用rhs's bitmap的副本（复件）
    return *this;    // 见条款10
}

这里的自我赋值问题是，operator=函数内的*this（赋值的目的端）和rhs有可能是同一个对象。果真如此delete就不只是销毁当前对象的bitmap，它也销毁rhs的bitmap。在函数末尾，Widget——它原本不该被自我赋值动作改变的——发现自己持有一个已被删除的对象。

欲阻止这种错误，传统做法是藉由operator=最前面的一个“证同测试（identity test）”达到“自我赋值”的检验目的：

Widget &Widget::operator=(const Widget &rhs)
{
    if (this == &rhs)    // 证同测试（identity test），如果是自我赋值，就什么也不做
    {
        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、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法，但它行得通。

如果你很关心效率，可以把“证同测试”再次放回函数起始处。然而这样做之前先问问自己，你估计“自我赋值”的发生频率有多高？因为这项测试也需要成本。它会使代码变大一些（包括原始码和目标码）并导入一个新的控制流（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)    // rhs是被传对象的一份副本，这里是pass by value
{
    swap(rhs);    // 将*this的数据和副本的数据互换
    return *this;
}

作者比较担心这个做法，它为了伶俐巧妙的fix而牺牲了清晰性。然而将“copying动作”从函数本体内移至“函数参数构造阶段”却可令编译器有时生成更高效的代码。

请记住：
1.确保当前对象自我复制时operator=有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、copy-and-swap。

2.确定任何函数如果操作一个以上的对象，而其中多个对象是同一个对象时，其行为仍然正确。