一旦程序員把注意力都轉向了對象傳值方式隱含的效率問題（參見條目20）時，許多人都變成了極端的“改革運動者”，他們對傳值方法采取斬草除根的態度，不屈不撓的追隨著一個純粹的傳遞引用的世界，與此同時，他們也無可避免的犯下了一個致命的錯誤：有時候傳遞的引用所指向的對象并不存在。這決不是一件好事情。
請看下面的示例，其中的Rational類用來表示有理數，還有一個函數用來計算兩個有理數的乘積：
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
// 條目24中解釋了為什么這里的構造函數
// 沒有聲明為explicit。
...
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已經毫無關系，因為它已經被銷毀了。對于所有的調用者而言，只要稍稍觸及這一函數的返回值，都會遭遇到無盡的未定義行為。事實上，任何返回局部對象引用的函數都是災難性的。（任何返回指向局部對象的指針的函數也是如此。）
現在，讓我們考慮下面做法的可行性：在堆上創建一個對象，然后返回一個指向它的引用。由于保存于堆上的對象由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))的值永遠為true。
我們為上面代碼中的判斷語句更換為函數的形式，這個問題就更加淺顯了：
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*返回值的構造和析構過程可以被安全的排除。當編譯器利用了這一事實（編譯器通常都會這樣做），你的程序就可以繼續按預期的行為執行，同時還會比你預期的快一些。
歸根結底，是使用引用返回，還是直接返回一個對象？你的工作就是：做出正確的抉擇，使程序擁有正確的行為。然后把優化工作留給編譯器制造商，他們會致力于讓你的選擇執行起來更高效。
時刻牢記
l 對于局部的/分配于棧上/分配于堆上的對象，如果你需要將其中的任意一種作為函數的返回值，請確保做到以下幾點：不要返回一個指向局部的、分配于棧上的對象；不要返回一個引用去指向分配于堆上的對象；不要返回一個指向局部靜態對象的指針或引用。（另有條目4中包含一個示例告訴我們：至少在在單線程環境下，返回一個指向局部靜態對象的指針還是有意義的。）