在operator=中处理“自我赋值”——条款11_条款 11:在 operator= 中处理“自我赋值”-优快云博客

本文链接：https://blog.youkuaiyun.com/yj_android_develop/article/details/102667864

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

class Widget {...};

Widget w;

...

w = w; //赋值给自己

这看起来有点愚蠢，但它合法，所以不要认定客户绝不会那么做。此外赋值动作并不总是那么可被一眼辨识出来，例如：

a[i] = a[j]; //潜在的自我赋值

如果i和j有相同的值，这便是自我赋值。再看：

*px = *py; //潜在的自我赋值

如果px和py恰巧指向同一个东西，这也是自我赋值。

自我赋值有可能会掉进“在停止使用资源之前以外释放了它”的陷阱。假设你建立一个class用来保存一个指针指向一块动态分配的位图（bitmap）：

class Bitmap {...};
class Widget {
    ...
private:
    Bitmap* bp;
};

下面是operator=实现代码，表面上看起来合理，但自我赋值出现时并不安全（它也不具备异常安全性，但我们稍后才讨论这个主题）。

Widget& Widget::operator=(const Widget& rhs)
{
    delete pb;
    pb = new Bitmap(*rhs.pb);
    return *this;
}

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

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

Widget& Widget::operator=(const Widget& rhs)
{
    if (this == &rhs) return *this;  //证同测试：如果是自我赋值，就不做任何事。
    delete pb;
    pb = new Bitmap(*rhs.pb);
    return *this;
}

这样做行得通。但是如果“new Bitmap”导致异常（不论是因为分配时内存不足或因为Bitmap的copy构造函数抛出异常），Widget最终会持有一个指针指向一块被删除的Bitmap。

解决方法：

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）保持原状。即使没有证同测试，这段代码还是能够处理自我赋值，因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法，但它行得通。

在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;
}