? ? ? ?缺省情況下C++ 以by value方式(一個繼承自C 的方式)傳遞對象至(或來自)函數(shù)。函數(shù)參數(shù)都是以實際實參的復(fù)件(副本)為初值。這些復(fù)件(副本)系由對象的copy構(gòu)造函數(shù)產(chǎn)出，這可能使得pass-by-value成為昂貴的(費(fèi)時的)操作?？紤]以下class 繼承體系:

class?Person?{??
public:??
????Person?();??
????virtual?~Person();??
????......??
private:??
????std::string?name;??
????std::string?address;??
};??
class?Student:?public?Person?{??
public:??
????Student();??
????~Student();??
????......??
private:??
????std::string?schoolName;??
????std::string?schoolAddress;??
};

? ? ? ?現(xiàn)在考慮以下代碼，其中調(diào)用函數(shù)validateStudent ，后者需要一個Student 實參(by value) 并返回它是否有效:

bool?validateStudent(Student?s);????????//?函數(shù)以by?value方式接受學(xué)生??
Student?plato;??????????????????????????//?柏拉圖，蘇格拉底的學(xué)生??
bool?platoIsOK?=?validateStudent(plato);//?調(diào)用函數(shù)

? ? ? ?當(dāng)上述函數(shù)被調(diào)用時，發(fā)生什么事?
? ? ? ?無疑地Student 的copy構(gòu)造函數(shù)會被調(diào)用，以plato 為藍(lán)本將s 初始化。同樣明顯地，當(dāng)validateStudent遺回s 會被銷毀。因此，對此函數(shù)而言，參數(shù)的傳遞成本是"一次Student copy構(gòu)造函數(shù)調(diào)用，加上一次Student析構(gòu)函數(shù)調(diào)用"。
? ? ? ?但那還不是整個故事喔。Student對象內(nèi)有兩個string對象，所以每次構(gòu)造一個Student對象也就構(gòu)造了兩個string對象。此外Student 對象繼承自Person 對象，所以每次構(gòu)造Student對象也必須構(gòu)造出一個Person對象。一個Person對象又有兩個string對象在其中，因此每一次Person構(gòu)造動作又需承擔(dān)兩個string構(gòu)造動作。最終結(jié)果是，以by value方式傳遞一個Student對象會導(dǎo)致調(diào)用一次Student copy構(gòu)造函數(shù)、一次Person copy 構(gòu)造函數(shù)、四次string copy 構(gòu)造函數(shù)。當(dāng)函數(shù)內(nèi)的那個Student復(fù)件被銷毀，每一個構(gòu)造函數(shù)調(diào)用動作都需要一個對應(yīng)的析構(gòu)函數(shù)調(diào)用動作。因此，以by value 方式傳遞一個Student對象，總體戚本是"六次構(gòu)造函數(shù)和六次析構(gòu)函數(shù)" !

? ? ? ?這是正確且值得擁有的行為，畢竟你希望你的所有對象都能夠被確實地構(gòu)造和析構(gòu)。但盡管如此，如果有什么方法可以回避所有那些構(gòu)造和析構(gòu)動作就太好了。有的，就是pass by reference-to-const:

bool?validateStudent(const?Student&?s);

? ? ? ? 這種傳遞方式的效率高得多:沒有任何構(gòu)造函數(shù)或析構(gòu)函數(shù)被調(diào)用，因為沒有任何新對象被創(chuàng)建。修訂后的這個參數(shù)聲明中的const 是重要的。原先的validateStudent以by value 方式接受一個Student參數(shù)，因此調(diào)用者知道他們受到保護(hù)，函數(shù)內(nèi)絕不會對傳入的Student 作任何改變; validateStudent只能夠?qū)ζ鋸?fù)件(副本)做修改?，F(xiàn)在Student 以by reference 方式傳遞，將它聲明為const 是必要的，因為不這樣做的話調(diào)用者會憂慮validateStudent會不會改變他們傳入的那個Student。

? ? ? ?以by reference方式傳遞參數(shù)也可以避免slicing ( 對象切割)問題。當(dāng)一個derived class 對象以by value方式傳遞并被視為一個base class 對象， base class 的copy構(gòu)造函數(shù)會別調(diào)用，而"造成此對象的行為像個derived class 對象"的那些特化性質(zhì)全被切割掉了，僅僅留下一個base class 對象。這實在不怎么讓人驚訝，因為正是base class 構(gòu)造函數(shù)建立了它。但這幾乎絕不會是你想要的。假設(shè)你在一組classes 上工作，用來實現(xiàn)一個圖形窗口系統(tǒng)：

class?Window?{??
public:???
????......??
????std::string?name()?const;????//?返回窗口名稱??
????virtual?void?display()?const;//?顯示窗口和其內(nèi)容??
};??
class?WindowWithScrollBars:?public?Window?{??
public:??
????......??
????virtual?void?display{}?const;??
};

? ? ? ? 現(xiàn)在假設(shè)你希望寫個函數(shù)打印窗口名稱，然后顯示該窗口。下面是錯誤示范:

void?printNameAndDisplay(Window?w)//?不正確!參數(shù)可能被切割。??
{??
????std::cout?<<?w.name();??
????w.display()?;??
}

? ? ? ?當(dāng)你調(diào)用上述函數(shù)并交給它一個WindowWithScrollBars 對象，會發(fā)生什么事呢?

WindowWithScrollBars?wwsb;??
printNameAndDisplay(wwsb);

? ? ? ?喔，參數(shù)W 會被構(gòu)造成為一個Window對象:它是passed by value ，還記得嗎?而造成wwsb" 之所以是個WindowWithScrollBars 對象"的所有特化信息都會被切除。在printNameAndDisplay 函數(shù)內(nèi)不論傳遞過來的對象原本是什么類型，參數(shù)w 就像一個Window 對象(因為其類型是Window) 。因此在printNameAndDisplay 內(nèi)調(diào)用display調(diào)用的總是Window::display，絕不會是WindowWithScrollBars::display。

? ? ? ?解決切割(slicing) 問題的辦法，就是以by reference-to- const 的方式傳遞w:

void?printNameAndDisplay(const?Window&?w)//?很好，參數(shù)不會被切割??
{??
????std::cout?<<?w.name()?;??
????w.display();??
}

? ? ? ?現(xiàn)在，傳進(jìn)來的窗口是什么類型，w 就表現(xiàn)出那種類型。
? ? ? 如果窺視C++ 編譯器的底層，你會發(fā)現(xiàn)， references往往以指針實現(xiàn)出來，因此pass by reference 通常意味真正傳遞的是指針。因此如果你有個對象屬于內(nèi)置類型(例如int) , pass by value 往往比pass by reference 的效率高些。對內(nèi)置類型而言，當(dāng)你有機(jī)會選擇采用pass-by-value或pass-by-reference-to-const 時，選擇pass-by-value并非沒有道理。這個忠告也適用于STL 的選代器和函數(shù)對象，因為習(xí)慣上它們都被設(shè)計為passed by value。迭代器和函數(shù)對象的實踐者有責(zé)任看看它們是否高效且不受切割問題(slicing problem) 的影響。
? ? ? ?內(nèi)置類型都相當(dāng)小，因此有人認(rèn)為，所有小型types 都是pass-by-value的合格候選人，甚至它們是用戶自定義的class 亦然。這是個不可靠的推論。對象小并不就意味其copy構(gòu)造函數(shù)不昂貴。許多對象一一包括大多數(shù)STL 容器一一內(nèi)含的東西只比一個指針多一些，但復(fù)制這種對象卻需承擔(dān)"復(fù)制那些指針?biāo)傅拿恳粯訓(xùn)|西"。那將非常昂貴。
? ? ? ?即使小型對象擁有并不昂貴的copy構(gòu)造函數(shù)，還是可能有效率上的爭議。某些編譯器對待"內(nèi)置類型"和"用戶自定義類型"的態(tài)度截然不同，縱使兩者擁有相同的底層表述(underlying representation) 。舉個例子，某些編譯器拒絕把只由一個double組成的對象放進(jìn)緩存器內(nèi)，卻很樂意在一個正規(guī)基礎(chǔ)上對光禿禿的doubles 那么做。當(dāng)這種事發(fā)生，你更應(yīng)該以by reference 方式傳遞此等對象，因為編譯器當(dāng)然會將指針(references的實現(xiàn)體)放進(jìn)緩存器內(nèi)，絕無問題。
? ? ? ?"小型的用戶自定義類型不必然成為pass-by-value優(yōu)良候選人"的另一個理由是，作為一個用戶自定義類型，其大小容易有所變化。一個type 目前雖然小，將來也許會變大，因為其內(nèi)部實現(xiàn)可能改變。甚至當(dāng)你改用另一個C++ 編譯器都有可能改變type的大小。舉個例子，在我下筆此刻，某些標(biāo)準(zhǔn)程序庫實現(xiàn)版本中的string 類型比其他版本大七倍。

? ? ? ?一般而言，你可以合理假設(shè)" pass-by-value 并不昂貴"的唯一對象就是內(nèi)置類型和STL 的迭代器和函數(shù)對象。至于其他任何東西都請遵守本條款的忠告，盡量以pass-by-reference-to-const 替換passφy-value。

需要記住的
1.盡量以pass-by-reference-to-const替換pass-by-value。前者通常比較高效，并可避免切割問題(slicing problem) 。
2.以上規(guī)則并不適用于內(nèi)置類型，以及STL 的迭代器和函數(shù)對象。對它們而言，pass-by-value往往比較適當(dāng)。