一旦程序員把注意力都轉(zhuǎn)向了對象傳值方式隱含的效率問題（參見條目20）時，許多人都變成了極端的“改革運動者”，他們對傳值方法采取斬草除根的態(tài)度，不屈不撓的追隨著一個純粹的傳遞引用的世界，與此同時，他們也無可避免的犯下了一個致命的錯誤：有時候傳遞的引用所指向的對象并不存在。這決不是一件好事情。
請看下面的示例，其中的Rational類用來表示有理數(shù)，還有一個函數(shù)用來計算兩個有理數(shù)的乘積：
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
// 條目24中解釋了為什么這里的構(gòu)造函數(shù)
// 沒有聲明為explicit。
...
private:
int n, d; // 分子（n）和分母（d）
friend const Rational
operator*(const Rational& lhs, const Rational& rhs);
// 條目3中解釋了為什么返回值是const的。
};
這一版本的operator*通過傳值方式返回一個對象，如果你不去考慮這一對象在構(gòu)造和析構(gòu)過程中的開銷，那么你就是在逃避你的專業(yè)職責(zé)。如果你并不是非得要為這樣的對象付出代價，那么你大可不必那樣做。現(xiàn)在問題就是：你必須付出這一代價嗎？
好的，如果此時你可以返回一個引用作為替代品，那么就不需要了。但是請記住，一個引用僅僅是一個名字，它是一個已存在對象的別名。當(dāng)你看到一個引用的聲明時，你應(yīng)該立刻問一下你自己：它的另一個名字是什么，因為一個引用所指向的內(nèi)容必定有它自己的名字。于是對于上面的operator*而言，如果它返回一個引用，那么它所引用的必須是一個已存在的Rational對象，這個對象中包含著需要進行乘法操作那兩個對象的乘積。
這里我們沒有理由期望在調(diào)用operator*之前這一對象必須存在。也就是說，如果你這樣做了：
Rational a(1, 2); // a = 1/2
Rational b(3, 5); // b = 3/5
Rational c = a * b; // c 的值應(yīng)該為3/10
這里并沒有理由期待此處已經(jīng)存在一個值為3/10的有理數(shù)。其實并不是這樣的，如果operator*返回一個指向這類數(shù)值的引用，那么它必須要自己創(chuàng)建這個數(shù)字。
一個函數(shù)只能以兩種方式創(chuàng)建新的對象：在棧上或在堆上。在棧上創(chuàng)建一個新對象是通過定義一個局部變量完成的。應(yīng)用這一策略時，你可能會以這種方式編寫operator*：
const Rational& operator*(const Rational& lhs, const Rational& rhs)
// 警告！錯誤的代碼
{
Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
}
你完全可以拒絕這樣的實現(xiàn)方法，因為你的目標(biāo)是防止對構(gòu)造函數(shù)的調(diào)用，但是此時result會像其它對象一樣被初始化。一個更嚴(yán)重的問題是：這個函數(shù)會返回一個指向result的引用，但是result是一個局部對象，而局部對象在函數(shù)退出時就會被銷毀。那么，這一版本的operator*，并不會返回一個指向Rational的引用，它返回的引用指向一個“前Rational”，一個“空寂的、散發(fā)著霉氣的、開始腐爛的尸體”，它曾經(jīng)是一個Rational對象，但它現(xiàn)在與Rational已經(jīng)毫無關(guān)系，因為它已經(jīng)被銷毀了。對于所有的調(diào)用者而言，只要稍稍觸及這一函數(shù)的返回值，都會遭遇到無盡的未定義行為。事實上，任何返回局部對象引用的函數(shù)都是災(zāi)難性的。（任何返回指向局部對象的指針的函數(shù)也是如此。）
現(xiàn)在，讓我們考慮下面做法的可行性：在堆上創(chuàng)建一個對象，然后返回一個指向它的引用。由于保存于堆上的對象由new來創(chuàng)建，因此你可能會這樣編寫基于堆的operator*：
const Rational& operator*(const Rational& lhs, const Rational& rhs)
// 警告！更多的錯誤代碼！
{
Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
return *result;
}
好的，此時仍然需要付出調(diào)用構(gòu)造函數(shù)的代價，這是因為通過new分配的內(nèi)存要通過調(diào)用一個合適的構(gòu)造函數(shù)來初始化，但是現(xiàn)在你面臨這另一個問題：誰來確保與new相對應(yīng)的delete的執(zhí)行呢？
即使調(diào)用者十分認(rèn)真負(fù)責(zé)并且抱有良好的初衷，他們也無法保證下面這樣合理的使用場景下不會出現(xiàn)內(nèi)存泄漏：
Rational w, x, y, z;
w = x * y * z; // 等價于operator*(operator*(x, y), z)
這里，在一個語句中存在著兩次對operator*的調(diào)用，于是存在兩次new操作有待于使用delete來清除。但是又沒有任何理由要求operator*的客戶來進行這一操作，這是因為對operator*的調(diào)用返回了一個引用，沒有理由要求客戶去取得隱藏在這一引用背后的指針。這勢必會造成資源泄漏。
但是，也許你注意到了，棧方案與堆方案都面臨著同一個問題：它們都需要為operator*的每一個返回值調(diào)用一次構(gòu)造函數(shù)。也許你能夠回憶起我們最初的目的就是避免像此類構(gòu)造函數(shù)調(diào)用。也許你認(rèn)為你知道某種方法來將此類構(gòu)造函數(shù)調(diào)用的次數(shù)降低到僅有一次。也許你想到了下面的實現(xiàn)方法：讓operator*返回一個指向一個靜態(tài)的Rational對象的引用（這一靜態(tài)對象放置于函數(shù)的內(nèi)部）：
const Rational& operator*(const Rational& lhs, const Rational& rhs)
// 警告！更多更多的錯誤代碼！
{
static Rational result; // 用來作為返回值的靜態(tài)對象
result = ... ; // 將lhs與rhs相乘，
// 并將乘積存入result
return result;
}
與其它引入靜態(tài)對象的設(shè)計方法一樣，這種方法很顯著的提高了線程的安全性，但是這卻帶來了更明顯的缺陷。下面的客戶端代碼是無懈可擊的，但是上文中的設(shè)計會使其暴露出更深層次的缺陷：
bool operator==(const Rational& lhs, const Rational& rhs);
// 為有理數(shù)作比較的operator==
Rational a, b, c, d;
...
if ((a * b) == (c * d)) {
當(dāng)乘積相等時，執(zhí)行恰當(dāng)?shù)牟僮?/span>;
} else {
當(dāng)乘積不相等時，執(zhí)行恰當(dāng)?shù)牟僮?/span>;
}
猜猜會發(fā)深什么？無論a、b、c或d取什么值，表達式((a*b) == (c*d))的值永遠為true。
我們?yōu)樯厦娲a中的判斷語句更換為函數(shù)的形式，這個問題就更加淺顯了：
if (operator==(operator*(a, b), operator*(c, d)))
請注意，在調(diào)用operator==時，已經(jīng)存在了兩次活動的operator*調(diào)用，每次調(diào)用時都回返回一個指向operator*內(nèi)部的靜態(tài)Rational對象的引用。于是編譯器將要求operator==去將operator*內(nèi)部的靜態(tài)Rational對象與自身相比較。如果結(jié)果不相等，才是讓人吃驚的事情。
上面的內(nèi)容似乎已經(jīng)足夠讓你確信：為類似于operator*這樣的函數(shù)返回一個引用確實是在浪費時間，但是有些時候你會想：“好吧，一個靜態(tài)值不夠，那么用一個靜態(tài)數(shù)組總可以了吧…”
我無法用實例來捍衛(wèi)我的觀點，但是我可以用非常簡明的推理證明這樣做會讓你多羞愧：首先，你必須確定一個n值，也就是數(shù)組的大小。如果n太小了，函數(shù)返回值的存儲空間可能會用完，這種情況與剛才否定的單一靜態(tài)對象的方案一樣糟糕。但是如果n的值太大，那么你的程序?qū)⒚媾R性能問題，這是因為數(shù)組中的每個對象都應(yīng)在函數(shù)在第一次調(diào)用時被構(gòu)造。這會使你付出n次構(gòu)造函數(shù)和n次析構(gòu)函數(shù)調(diào)用的代價，即使我們討論的函數(shù)只被調(diào)用一次。如果將“優(yōu)化”稱為改善軟件性能的一個步驟，那么我們可以把這一做法稱為“劣化”。最后，請考慮一下：你如何將需要的值放入數(shù)組中的對象里，在放置的過程中你又付出了多大代價呢？在兩個對象之間傳值的最直接的方法就是賦值，但是賦值操作又會帶來多大開銷呢？對于許多類型而言，賦值的開銷類似于調(diào)用一次析構(gòu)函數(shù)（以銷毀舊數(shù)值）加上一次構(gòu)造函數(shù)（以復(fù)制新數(shù)值）。但是要知道，你的原始目標(biāo)本來是避免構(gòu)造和析構(gòu)過程所帶來的開銷！請面對它：這樣做一定不會得到好結(jié)果。（別妄想，用vector來代替數(shù)組也不會改善多少。）
在編寫必須返回一個新對象的函數(shù)時，正確的方法就是讓這個函數(shù)返回一個新對象。對于Rational的operator*來說，這就意味著下面的代碼是基本符合要求的：
inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{
return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}
顯然地，這樣做可能會招致對operator*的返回值的構(gòu)造和析構(gòu)過程的開銷，但是從長遠角度講，付出這小小的代價可以獲得更大的收益。而且，這一可能會嚇到你的清單也許永遠不需要你來付賬。就像其它編程語言一樣，C++允許編譯器的具體實現(xiàn)版本在不改變其固有行為的同時通過優(yōu)化代碼來提升性能，在某些情況下，對operator*返回值的構(gòu)造和析構(gòu)過程可以被安全的排除。當(dāng)編譯器利用了這一事實（編譯器通常都會這樣做），你的程序就可以繼續(xù)按預(yù)期的行為執(zhí)行，同時還會比你預(yù)期的快一些。
歸根結(jié)底，是使用引用返回，還是直接返回一個對象？你的工作就是：做出正確的抉擇，使程序擁有正確的行為。然后把優(yōu)化工作留給編譯器制造商，他們會致力于讓你的選擇執(zhí)行起來更高效。
時刻牢記
l 對于局部的/分配于棧上/分配于堆上的對象，如果你需要將其中的任意一種作為函數(shù)的返回值，請確保做到以下幾點：不要返回一個指向局部的、分配于棧上的對象；不要返回一個引用去指向分配于堆上的對象；不要返回一個指向局部靜態(tài)對象的指針或引用。（另有條目4中包含一個示例告訴我們：至少在在單線程環(huán)境下，返回一個指向局部靜態(tài)對象的指針還是有意義的。）