在必須返回一個對象時，不要去嘗試返回一個引用

標籤：http   使用   io   strong   for   問題   代碼   工作   

一旦程式員把注意力都轉向了對象傳值方式隱含的效率問題（參見第 20 條）時，許多人都變成了極端的“改革運動者”，他們對傳值方法採取斬草除根的態度，在他們不屈不撓追求傳遞引用方式的純粹性的同時，他們也犯下了致命的錯誤：有時候傳遞的引用所指向的對象並不存在。這決不是一件好事情。

請看下面的樣本，其中的 Rational 類用來表示有理數，其中還包括一個函數來計算兩個有理數的乘積：

class Rational {
public:
  Rational(int numerator = 0, int denominator = 1);
  // 第 24 條中解釋了為什麼這裡的建構函式沒有顯性聲明。
  ...

private:
  int n, d;  // 分子（ n ）和分母（ d ）

friend const Rational
         operator*(const Rational& lhs, const Rational& rhs);
  // 第 3 條中解釋了為什麼傳回值是 const 的。
};

這一版本的 operator* 通過傳值方式返回一個對象，如果你不去考慮這一對象在構造和析構過程中的開銷，那麼你就是在逃避你的專業職責。如果你並不是非得要為這樣的對象付出代價，那麼你大可不必那樣做。現在問題就是：你必須付出這一代價嗎？

好的，如果此時你可以返回一個引用作為替代品，那麼就不需要了。但是請記住，一個引用僅僅是一個名字，它是一個已存在的對象的別名。當你看到一個引用的聲明時，你應該立刻問一下你自己：它的另一個名字是什麼，因為一個引用作指向的內容必定有它自己的名字。於是對於上面的 operator* 而言，如果它返回一個引用，那麼它所引用的必須是一個已存在的 Rational 對象，這個對象中包含著需要進行乘法操作的兩個對象的乘積。

如果你期望在調用 operator* 之前這一對象必須存在，那麼你就太不理智了。也就是說，如果你這樣做了：

Rational a(1, 2);   // a = 1/2
Rational b(3, 5);   // b = 3/5
Rational c = a * b;   // c 的值應該為 3/10

期待存在一個值為 3/10 的有理數的做法看上去顯得很不理智。其實並不是這樣的，如果 operator* 返回一個指向這類數值的引用，那麼它必須要自己建立這個數字。

一個函數只能以兩種方式建立新的對象：在棧上或在堆上。定義一個局部變數就是在棧上建立一個新對象。應用這一策略時，你可能會以這種方式編寫 operator* ：

const Rational& operator*(const Rational& lhs, const Rational& rhs)
    // 警告！錯誤的代碼
{
  Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
  return result;
}

你大可以拒絕這樣的實現方法，因為你的目標是防止對建構函式的調用，但是此時 result 會像其它對象一樣被初始化。一個更嚴重的問題是：這個函數會返回一個指向 result 的引用，但是 result 是一個局部對象，而局部對象在函數退出時就會被銷毀。那麼，這一版本的 operator* ，並不會返回一個指向 Rational 的引用，它返回的引用指向一個“前期 Rational ”，它曾經是 Rational 的對象，一個“空寂的、散發著黴氣的、開始腐爛的、曾是一個 Rational 的屍體”，但它現在與 Rational 已經毫無關係，因為它已經被銷毀了。對於所有的調用者而言，只要稍稍觸及這一函數的傳回值，都會遭遇到無盡的無法預知的行為。事實上，任何返回局部對象引用的函數都是災難性的。（任何返回指向局部對象的指標的函數也是如此。）

現在，讓我們考慮下面做法的可行性：在堆上建立一個對象，然後返回一個指向它的引用。由於儲存於堆上的對象由 new 來建立，因此你可能會這樣編寫基於堆的 operator* ：

const Rational& operator*(const Rational& lhs, const Rational& rhs)
     // 警告！這裡有更多的錯誤！

{
  Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
  return *result;
}

好的，此時仍然需要付出調用建構函式的代 價，這是因為通過 new 分配的記憶體要通過調用一個合適的建構函式來初始化，但是現在你面臨這另一個問題：誰來確保與 new 相對應的 delete 的執行呢？

即使調用者十分認真負責並且抱有良好的初衷，他們也無法保證：下面這樣合理的使用情境下不會出現記憶體流失：

Rational w, x, y, z; 
w = x * y * z; // 等價於 operator*(operator*(x, y), z)

這裡，在一個語句中存在著兩次對 operator* 的 調用，於是存在兩次 new 操作有待於使用 delete 來清除。但是又沒有任何理由要求 operator* 的用戶端程式員來進行這一操作，這是因為對 operator* 的調用返回了一個引用，沒有理由要求用戶端程式員去取得隱藏在這一引用背後的指標。這勢必會造成資源泄漏。

但是，也許你注意到了，棧方案與堆方案都面臨著同一個問題：它們都需要為 operator* 的每一個傳回值調用一次建構函式。也許你能夠回憶起我們最初的目的就是避免像此類建構函式調用。也許你認為你知道某種方法來將此類建構函式調用的次數降低到僅有一次。也許你想到了下面的實現方法：讓 operator* 返回一個指向一個靜態 Rational 對象的引用，這一靜態對象在函數的內部：

const Rational& operator*(const Rational& lhs, const Rational& rhs)
  // 警告！會出現更多更多的錯誤！
{
  static Rational result;    // 用來作為傳回值的靜態對象
  result = ... ;   // 將 lhs 與 rhs 相乘， 並將乘積存入 result

  return result;
}

與其它引入靜態對象的設計方法一樣，這種方法很顯著的提高了線程的安全性，但是這卻帶來了更明顯的缺陷。下面的用戶端代碼是無懈可擊的，但是上文中的設計會使其暴露出問題：

bool operator==(const Rational& lhs, const Rational& rhs);
    // 為有理數作比較的 operator==

Rational a, b, c, d; 
...
if ((a * b) == (c * d))  {
    當乘積相等時，執行恰當的操作 ;
} else    {
    當乘積不相等時，執行恰當的操作 ;
}

猜猜會發深什嗎？無論 a 、 b 、 c 或 d 取什麼值，運算式 ((a*b) == (c*d)) 的值永遠為真。

我們為上面函數中的判斷語句更換一個形式，這個問題就更加淺顯了：

if (operator==(operator*(a, b), operator*(c, d)))

請注意，在調用 operator== 時，已經存在了兩次活動的對 operator* 的調用，每次調用時都回返回一個指向 operator* 內部的靜態 Rational 對象的引用。於是編譯器將要求 operator== 去將 operator* 內部的靜態 Rational 對象與自身相比較。如果結果並不總是相等的，這才是讓人奇怪的事情。

上面的內容似乎已經足夠讓你確信：為類似於 operator* 這樣的函數返回一個引用確實是在浪費時間，但是有些時候你會想：“好吧，一個靜態值不夠，那麼用一個靜態數組總可以了吧 … ”

我無法用執行個體來捍衛我的觀點，但是我可以用非常簡明的推理證明這樣做會讓你多羞愧：首先，你必須確定一個 n 值，也就是數組的大小。如果 n 太小了，函數傳回值的儲存空間可能會用完，這種情況與剛才否定的單一靜態對象的方案一樣糟糕。但是如果 n 的值太大，那麼你的程式將面臨效能問題，這是因為數組中的每個對象都應在函數在第一次調用時被構造。這會使你付出 n 次建構函式和 n 次解構函式的調用，即使我們討論的函數只被調用一次。如果將“最佳化”稱為改善軟體效能的一個步驟，那麼我們可以把這一做法稱為“劣化”。最後，請考慮一下：你如何將需要的值放入數組中的對象裡，在放置的過程中你又付出了多大代價呢？在兩個對象之間傳值的最直接的方法就是賦值，但是賦值操作又會帶來多大開銷呢？對於許多類型而言，賦值的開銷類似於調用一次解構函式（以銷毀舊數值）加上一次建構函式（以複製新數值）。但是要知道，你的原始目標本來是避免構造和析構過程所帶來的開銷！請面對它：這樣做一定不會得到好結果。（別妄想，用 vector 來代替數組也不會改善多少。）

編寫必須返回一個新對象的函數，正確的方法就是：讓這個函數返回一個新對象。對於 Rational 的 operator* 來說，這就意味著下面的代碼是基本符合要求的：

inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{
  return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

顯然地，這樣做可能會招致對 operator* 的傳回值的構造和析構過程的開銷，但是從長遠角度講，付出這小小的代價可以獲得更大的收益。而且，這一恐怖的清單可能永遠不需要你來付賬。就像其它程式設計語言一樣，C++允許編譯器的具體實現版本通過最佳化代碼來提升效能，同時又不改變其固有的行為，在一些情況下，對 operator* 傳回值的構造和析構過程可以被安全的排除。當編譯器利用了這一事即時（編譯器通常都會這樣做），你的程式就可以繼續按預期的行為執行，僅僅是更快了一些。

歸根結底，當選擇是使用引用返回，還是直接返回一個對象時，你的工作就是：做出正確的抉擇，使程式擁有正確的行為。然後把最佳化工作留給編譯器製造商，他們會使你的抉擇變得儘可能的經濟實用。

牢記在心

• 對於局部的 / 分配於棧上 / 分配於堆上的對象，如果你需要將其中的任意一種作為函數的傳回值