默認情況下，C++為函數傳入和傳出對象是采用傳值方式的（這是由C語言繼承而來的特征）。除非你明確使用其他方法，函數的形式參數總會通過復制實在參數的副本來創建，并且，函數的調用者得到的也是函數返回值的一個副本。這些副本是由對象的拷貝構造函數創建的。這使得“傳值”成為一項代價十分昂貴的操作。請觀察下邊的示例中類的層次結構：
class Person {
public:
Person(); // 省略參數表以簡化代碼
virtual ~Person(); // 條目7解釋了它為什么是虛函數
...
private:
std::string name;
std::string address;
};
class Student: public Person {
public:
Student(); // 再次省略參數表
virtual ~Student();
...
private:
std::string schoolName;
std::string schoolAddress;
};
請觀察下面的代碼，這里我們調用一個名為validateStudent的函數，通過為這一函數傳進一個Student類型的參數（傳值方式），它將返回這一學生的身份是否合法：
bool validateStudent(Student s); // 通過傳值方式接受一個Student對象
Student plato; // 柏拉圖是蘇格拉底的學生
bool platoIsOK = validateStudent(plato); // 調用這一函數
在這個函數被調用時將會發生些什么呢？
很顯然地，在這一時刻，通過調用Student的拷貝構造函數，可以將這一函數的s參數初始化為plato的值。同樣顯然的是，s在validateStudent返回的時候將被銷毀。所以這一函數中傳參的開銷就是調用一次Student的拷貝構造函數和一次Student的析構函數。
但是上邊的分析僅僅是冰山一角。一個Student對象包含兩個string對象，所以每當你構造一個Student對象時，你都必須構造兩個string對象。同時，由于Student類是從Person類繼承而來，所以在每次構造Student對象時，你都必須再構造一個Person對象。一個Person對象又包含兩個額外的string對象，所以每次對Person的構造還要進行額外的兩次string的構造。最后的結果是，通過傳值方式傳遞一個Student對象會引入以下幾個操作：調用一次Student的拷貝構造函數，調用一次Person的拷貝構造函數，調用四次string的拷貝構造函數。在Student的這一副本被銷毀時，相應的每次構造函數調用都對應著一次析構函數的調用。因此我們看到：通過傳值方式傳遞一個Student對象總體的開銷究竟有多大？竟達到了六次構造函數和六次析構函數的調用！
下面向你介紹正確的方法，這一方法才會使函數擁有期望的行為。畢竟你期望的是所有對象以可靠的方式進行初始化和銷毀。與此同時，如果可以繞過所有這些構造和析構操作將是件很愜意的事情。這個方法就是：通過引用常量傳遞參數：
bool validateStudent(const Student& s);
這樣做效率會提高很多：由于不會創建新的對象，所以就不會存在構造函數或析構函數的調用。改進的參數表中的const是十分重要的。由于早先版本的validateStudent通過傳值方式接收Student參數，所以調用者了解：無論函數對于傳入的Student對象進行什么樣的操作，都不會對原對象造成任何影響，validateStudent僅僅會對對象的副本進行修改。而改進版本中Student對象是以引用形式傳入的，有必要將其聲明為const的，因為如果不這樣，調用者就需要關心傳入validateStudent的Student對象有可能會被修改。
通過引用傳參也可以避免“截斷問題”。當一個派生類的對象以一個基類對象的形式傳遞（傳值方式）時，基類的拷貝構造函數就會被調用，此時，這一對象的獨有特征——使它區別于基類對象的特征會被“截掉”。剩下的只是一個簡單的基類對象，這并不奇怪，因為它是由基類構造函數創建的。這肯定不是你想要的。請看下邊的示例，假設你正在使用一組類來實現一個圖形窗口系統：
class Window {
public:
...
std::string name() const; // 返回窗口的名字
virtual void display() const; // 繪制窗口和內容
};
class WindowWithScrollBars: public Window {
public:
...
virtual void display() const;
};
所有的Window對象都有一個名字，可以通過name函數取得。所有的窗口都可以被顯示出來，可以通過調用display實現。display是虛函數，這一事實告訴我們，簡單基類Window的對象與派生出的WindowWithScrollBars對象的顯示方式是不一樣的。（參見條目34和36）
現在，假設你期望編寫一個函數來打印出當前窗口的名字然后顯示這一窗口。下面是錯誤的實現方法：
void printNameAndDisplay(Window w) // 錯誤! 參數傳遞的對象將被截斷！
{
std::cout << w.name();
w.display();
}
考慮一下當你將一個WindowWithScrollBars對象傳入這個函數時將會發生些什么：
WindowWithScrollBars wwsb;
printNameAndDisplay(wwsb);
參數w將被構造為一個Window對象——還記得么？它是通過傳值方式傳入的。這里，使wwsb具體化的獨有信息將被截掉。無論傳入函數的對象的具體類型是什么，在printNameAndDisplay的內部，w將總保有一個Window類的對象的身份（因為它本身就是一個Window的對象）。特別地，在printNameAndDisplay內部對display的調用總是Window::display，而永遠不會是WindowWithScrollBars::display。
解決截斷問題的方法是：通過引用常量傳參：
void printNameAndDisplay(const Window& w)
{ // 工作正常，參數將不會被截斷。
std::cout << w.name();
w.display();
}
現在w的類型就是傳入窗口對象的精確類型。
揭開C++編譯器的面紗，你將會發現引用通常情況下是以指針的形式實現的，所以通過引用傳遞通常意味著實際上是在傳遞一個指針。因此，如果傳遞一個內建數據類型的對象（比如int），傳值會被傳遞引用更為高效。那么，對于內建數據類型，當你在傳值和傳遞常量引用之間徘徊時，傳值方式不失為一個更好的選擇。迭代器和STL中的函數對象也是如此，這是因為它們設計的初衷就是能夠更適于傳值，這是C++的慣例。迭代器和函數對象的設計人員有責任考慮復制時的效率問題和截斷問題。（這也是一個“使用哪種規則，取決于當前使用哪一部份的C++”的例子，參見條目1）
內建數據類型體積較小，所以一些人得出這樣的結論：所有體積較小的類型都適合使用傳值，即使它們是用戶自定義的。這是一個不可靠的推理。僅僅通過一個對象體積小并不能判定調用它的拷貝構造函數的代價就很低。許多對象——包括大多數STL容器——其中僅僅包含一個指針和很少量的其它內容，但是復制此類對象的同時，它所指向的所有內容都需要復制。這將付出十分高昂的代價。
即使體積較小的對象的拷貝構造函數不會帶來巨大的開銷，它也會引入性能問題。一些編譯器對內建數據類型和用戶自定義數據類型是分別對待的，即使它們的表示方式完全相同。比如說一些編譯器很樂意將一個單純的double值放入寄存器中，這是語言的常規；但將一個僅包含一個double值的對象放入寄存器時，編譯器就會報錯了。當你遇到這種事情時，你可以使用引用傳遞這類對象，因為編譯器此時一定會將指針（引用的具體實現）放入寄存器中。
對于“小型的用戶自定義數據類型不適用于傳值方式”還有一個理由，那就是：作為用戶自定義類型，它們的大小可能會改變。現在很小的類型在未來的版本中可能會變得很大，這是因為它的內部實現方式可能會改變。即使是你更改了C++語言的具體實現都可能會影響到類型的大小。比如，在我編寫上面的示例的時候，一些對標準庫實現中string的大小竟然達到了另一些的七倍。
總體上講，只有內建數據類型、STL迭代器和函數對象類型適用于傳值方式。對于所有其它的類型，都應該遵循本條款中的建議：盡量使用引用常量傳參，而不是傳值。
時刻牢記
l 盡量使用引用常量傳參，而不是傳值方式。因為一般情況下傳引用更高效，而且可以避免“截斷問題”。
l 對于內建數據類型、STL迭代和函數對象類型，這一規則就不適用了，對它們來說通常傳值方式更實用。