當對象為其自身賦值時，就發(fā)生了一次“自賦值”：
class Widget { ... };
Widget w;
...
w = w; // 自賦值
這樣做看上去很愚蠢，但是卻是合法的，因此客戶一定會這樣操做。而且，賦值工作本身并不總是那么容易辨認的。比如：
如果i和j的值相同，那么這就是一次自賦值。另外
在px和py指向同一處時，上面的代碼也是一次自賦值。這些自賦值并不是那么一目了然，它們是由別名造成的：可以通過多種方式引用同一個對象。一般來說，用來操作指向同一類型多個對象的引用或指針的代碼都應(yīng)考慮對象重復(fù)的問題。實際上，假如兩個對象來自同一層次，即使它們并未聲明為同一類型，也要考慮重復(fù)問題，這是因為一個基類的引用或指針可以引用或指向其派生類的類型的對象。
class Base { ... };
class Derived: public Base { ... };
void doSomething(const Base& rb, // rb 和 *pd 可能實際上
Derived* pd); // 是同一個對象
假設(shè)你遵循條目13和條目14中的建議，你將會一直使用對象來管理資源，而且在復(fù)制時你將會確保資源管理對象能正確工作。如果上邊的假設(shè)成立，你的賦值運算符很可能在處理自賦值時將是安全的，你不需要額外關(guān)注它。然而如果你試圖自己來管理資源（你在編寫資源管理類時一定會這樣做），此時你很有可能落入這個陷阱中：一個對象尚未用完，但是你卻不小心將其釋放了。比如說，你創(chuàng)建了一個類，其中放置了一個原始指針來動態(tài)分配位圖：
class Bitmap { ... };
class Widget {
...
private:
Bitmap *pb; // 指向一個分配在堆上的對象
};
下邊給出operator=的一個實現(xiàn)，它在表面看上去很合理，但是如果存在自賦值，它便是不安全的。（它也不是異常安全的，稍后我們討論這個問題）
Widget&
Widget::operator=(const Widget& rhs) // operator= 不安全的實現(xiàn)
{
delete pb; // 停止使用當前的位圖
pb = new Bitmap(*rhs.pb); // 開始使用rhs位圖的一份拷貝
return *this; // 參見條目10
}
此處的自賦值問題出現(xiàn)在operator=的內(nèi)部，*this（賦值操作的目標）和rhs有可能是同一對象。如果它們是，delete便不僅僅銷毀了當前對象的位圖，同時它也銷毀了rhs的位圖。Widget的值本不應(yīng)該在自賦值操作中改變，然而在函數(shù)的末尾，它會發(fā)現(xiàn)其包含的指針指向了一個已經(jīng)被刪除的對象！
防止這類錯誤發(fā)生的傳統(tǒng)方法是：在operator=的最頂端通過一致性檢測來監(jiān)視自賦值：
Widget& Widget::operator=(const Widget& rhs)
{
if (this == &rhs) return *this; // 一致性檢測： 如果出現(xiàn)自賦值
// 則什么也不做
delete pb;
pb = new Bitmap(*rhs.pb);
return *this;
}
這樣可以正常工作，但是上文提到的operator=先前的版本不僅僅是自賦值不安全的，同時也是異常不安全的。尤其在“new Bitmap”語句引發(fā)了一個異常（有可能是可分配內(nèi)存耗盡，或者是Bitmap的拷貝構(gòu)造函數(shù)拋出了一個異常）時，Widget最終將包含一個指向已被刪除的Bitmap的指針。這類指針是有毒的。你無法安全的刪除它們。你甚至沒辦法安全的讀取它們。此時你所做的唯一一件安全的事情也許就是耗費大量debug的精力去尋找這些指針的出處。
還好，在讓operator=在做到異常安全的同時，它同時也能做到自賦值安全。因此，忽略自賦值的問題而把目光集中在異常安全的問題上，就愈加合理了。條目29中深入討論異常安全的問題，但是通過本條已足以看出：在許多情況下，認真安排語句的次序可以使你的代碼做到異常安全（同時也是自賦值安全的）。比方說，這里我們只需要認真考慮：在我們沒有把pb所指向的對象復(fù)制出來以前，千萬不要刪除它：
Widget& Widget::operator=(const Widget& rhs)
{
Bitmap *pOrig = pb; // 記憶原始的 pb
pb = new Bitmap(*rhs.pb); // 讓 pb指向*pb的一個副本
delete pOrig; // 刪除原始的pb
return *this;
}
現(xiàn)在，如果“new Bitmap”拋出一個異常，pb（及其所在的Widget）就不會被改動。即使沒有進行一致性檢測，這段代碼也可以解決自賦值問題，這是因為我們?yōu)樵嘉粓D復(fù)制出了一個副本，并將原始版本刪除，然后讓pb指向我們復(fù)制出的那個副本。這也許不是解決自賦值問題的最高效的途徑，但是這樣做確實有效。
如果你考慮到效率問題，你可以重新考慮在程序最開端添加一致性檢測。然而在這樣做之前先問一下自己：你預(yù)計自賦值出現(xiàn)的有多頻繁，因為一致性檢測也有系統(tǒng)開銷。首先它使得代碼（源代碼和對象）的體積變得稍大一些，其次它也會為控制流引入一個分支，二者都會降低運行的速度。比如說，指令預(yù)讀、捕獲、管線分配等操作的執(zhí)行效率將會受到影響。
在operator=中手動安排語句可以確保實現(xiàn)同時做到異常安全和自賦值安全，這里有一個替代方案：使用一個稱為“復(fù)制并swap”的技術(shù)。由于這一技術(shù)更加貼近異常安全的議題，因此我們在條目29中討論它。這是編寫operator=的一個相當普遍的方法，這里看一下它一般實現(xiàn)的方法是值得的：
class Widget {
...
void swap(Widget& rhs); // 交換*this和rhs中的數(shù)據(jù);
... // 更多細節(jié)請參見條目29
};
Widget& Widget::operator=(const Widget& rhs)
{
Widget temp(rhs); // 為rhs的數(shù)據(jù)保存副本
swap(temp); // 使用上邊的副本與*this交換
return *this;
}
通過利用這些事實：(1)一個類的拷貝賦值運算符可以通過傳值方式傳參；(2)通過傳值即可傳遞某參數(shù)的副本（參見條目20），上述主題可以進行以下演化：
Widget& Widget::operator=(Widget rhs) // rhs是傳進對象的一份拷貝
{ // 請注意此處是傳值方式傳遞參數(shù)
swap(rhs); // 交換*this與rhs的數(shù)據(jù)
return *this;
}
從個人角度來講，我很擔心這一做法會通過犧牲清晰度來換取靈巧性，但是把復(fù)制操作從函數(shù)體中移出來，放在參數(shù)構(gòu)造的過程中，在一些場合確實能夠讓編譯器生成更加高效的代碼。
時刻牢記
l 在一個對象為自己賦值時，要確保operator=可以正常地運行。可以使用的技術(shù)有：比較源對象和目標對象的地址、謹慎安排語句順序、以及“復(fù)制并swap”。
l 在兩個或兩個以上的對象完全一樣時，要確保對于這些重復(fù)對象的操作可以正常運行。