Shuffy

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

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

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

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

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

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

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

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

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

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

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

即使調用者十分認真負責并且抱有良好的初衷，他們也無法保證：下面這樣合理的使用場景下不會出現內存泄漏：

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

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

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

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

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

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

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

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

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

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

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