MoreEffectiveC++:35個改善編程與設計的有效方法（中文版）

《MoreEffectiveC++:35個改善編程與設計的有效方法（中文版）》是Scott Meyers出版於2011年1月的圖書。

基本介紹

• 中文名：MoreEffectiveC++:35個改善編程與設計的有效方法
• 作者：Scott Meyers
• 出版日期：2011年1月
•  定價：59.00元

圖書信息

書名：More Effective C++：35個改善編程與設計的有效方法（中文版） 作者：[美]Scott Meyers 著 侯捷 譯

ISBN 978-7-121-12570-6

出版日期：2011年1月

定價：59.00元

內容簡介

繼Effective C++之後，Scott Meyers 於1996 推出這本“續集”。條款變得比較少，頁數倒是多了一些，原因是這次選材比“第一集”更高階，尤其是第5 章。Meyers 將此章命名為技術（techniques），並明白告訴你，其中都是一些patterns，例如virtual constructors，smart pointers，reference counting，proxy classes，double dispatching……這一章的每個條款篇幅都達15~30 頁之多，實在讓人有“山重水複疑無路，柳暗花明又一村”之嘆。

雖然出版年代稍嫌久遠，但本書並沒有第2 版，原因是當其出版之時（1996），C++ Standard已經幾乎定案，本書即依當時的標準草案而寫，其與現今的C++標準規範幾乎相同。而且可能變化的幾個彈性之處，Meyers也都有所說明與提示。讀者可以登錄作者提供的網址，看看上下兩集的勘誤與討論（數量之多，令人驚恐。幸好多是技術討論或文字斟酌，並沒有什麼重大誤失）。

編輯推薦

這是一本多方面發人深省的 C++ 書籍：不論在你偶爾用到的語言特性上，或是在你自以為十分熟悉的語言特性上。只有深刻了解 C++ 編譯器如何解釋你的代碼，你才有可能用C++ 語言寫出健壯的軟體。本書是協助你獲得此等層級的了解過程中，一份極具價值的資源。讀過本書之後，我感覺像是瀏覽了 C++ 編程大師所檢閱過的代碼，並獲得許多極具價值的洞見。

——Fred Wild, Vice President of Technology,

Advantage Software Technologies

本書內含大量重要的技術，這些技術是撰寫優良 C++ 程式所不可或缺的。本書解釋如何設計和實現這些觀念，以及潛伏在其他某些替代方案中的陷阱。本書亦含晚些加入的C++特性的詳細說明。任何人如果想要好好地運用這些新特性，最好買一本並且放在隨手可得之處，以備查閱。

——Christopher J. Van Wyk, Professor

Mathematics and Computer Science, Drew University

這是一本具備工業強度的最佳書籍。對於已經閱讀過 Effective C++ 的人，這是完美的續集。

——Eric Nagler, C++ Instructor and Author,

University of California Santa Cruz Extension

More Effective C++ 是一本無微不至且很有價值的書籍，是Scott 第一本書Effective C++ 的續集。我相信每一位專業的C++ 軟體開發人員都應該讀過並記憶Effective C++ 和 More Effective C++ 兩本書內的各種招式，以及其中重要（而且有時候不可思議）的語言的方方面面。我強烈推薦這兩本書給軟體開發人員、測試人員、管理人員……，每個人都可以從Scott 專家級的知識與卓越的表達能力中獲益。

——Steve Burkett, Software Consultant

譯序

C++ 是一門難學易用的語言！

C++ 的難學，不僅在其廣博的語法、語法背後的語義、語義背後的深層思維、深層思維背後的對象模型；C++ 的難學，還在於它提供了4種不同（相輔相成）的編程思維模型：procedural-based，object-based，object-oriented，generic paradigm。

世上沒有白吃的午餐。又要有效率，又要有彈性，又要前瞻望遠，又要回溯相容，又要能治大國，又要能烹小鮮，學習起來當然就不可能太簡單。

在如此龐大複雜的機制下，萬千使用者前赴後繼的動力是：一旦學成，妙用無窮。

C++ 相關書籍之多，車載斗量，如天上繁星，如過江之鯽。廣博如四庫全書者有之（The C++ Programming Language、C++ Primer），深奧如重山復水者有之（The Annotated C++ Reference Manual, Inside the C++ Object Model），細說歷史者有之（The Design and Evolution of C++, Ruminations on C++），獨沽一味者有之（Polymorphism in C++, Genericity in C++），獨樹一幟者有之（Design Patterns, Large Scale C++ Software Design, C++ FAQs），程式庫大全有之（The C++ Standard Library），另闢蹊徑者有之（Generic Programming and the STL），工程經驗之累積亦有之（Effective C++, More Effective C++, Exceptional C++）。

這其中，“工程經驗之累積”對已具 C++ 相當基礎的程式設計師而言，有著致命的吸引力與立竿見影的幫助。Scott Meyers 的Effective C++ 和 More Effective C++ 是此類佼佼，Herb Sutter 的 Exceptional C++ 則是後起之秀。

這類書籍的一個共同特色是輕薄短小，並且高密度地納入作者浸淫於 C++/OOP 領域多年而廣泛的經驗。它們不但開擴讀者的視野，也為讀者提供各種 C++/OOP 常見問題或易犯錯誤的解決模型。某些小範圍主題諸如“在base classes 中使用 virtual destructor”、“令operator= 傳回 *this 的 reference”，可能在百科型 C++ 語言書籍中亦曾概略提過，但此類書籍以深度探索的方式，讓我們了解問題背後的成因、最佳的解法，以及其他可能的牽扯。至於大範圍主題，例如smart pointers，reference counting，proxy classes，double dispatching，基本上已屬design patterns的層級！

這些都是經驗的累積和心血的結晶！

我很高興將以下兩本優秀書籍，規劃為一個系列，以鄭重的形式呈現給您：

1. Effective C++ 2/e, by Scott Meyers, AW 1998

2. More Effective C++, by Scott Meyers, AW 1996

本書不但與英文版頁頁對譯，保留索引，並加上譯註、交叉索引 、讀者服務 。

這套書將對於您的程式設計生涯帶來重大幫助。翻譯這套書籍的過程中，我感覺來自技術體會上的極大快樂。我祈盼（並相信）您在閱讀此書時擁有同樣的心情。

侯捷 2003/03/07 於台灣新竹

本書保留大量簡短易讀之英文術語，時而中英並陳。以下用語請讀者特別注意：

英文術語 本書譯詞 英文術語 本書譯詞

argument 自變數 （i.e. 實參） instantiated 實例化、具現化

by reference 傳址 library 程式庫

by value 傳值 resolve 決議

dereference 解引（i.e. 解參考） parameter 參數 （i.e. 形參）

evaluate 評估、核定 type 型別 （i.e. 類型）

instance 實例

譯註：藉此版面提醒讀者，本書之中如果出現“條款5”這樣的參考指示，指的是本書條款5；如果出現“條款E5”這樣的參考指示，E 是指 Effective C++ 2/e）

導讀

對C++ 程式設計師而言，日子似乎有點過於急促。雖然只商業化不到 10 年，C++卻儼然成為幾乎所有主要計算環境的系統程式語言霸主。面臨程式設計方面極具挑戰性問題的公司和個人，不斷投入 C++ 的懷抱。而那些尚未使用 C++ 的人，最常被詢問的一個問題則是：你打算什麼時候開始用 C++。C++ 標準化已經完成，其所附帶的標準程式庫幅員廣大，不僅涵蓋 C 函式館，也使之相形見絀。這么一個大型程式庫使我們有可能在不必犧牲移植性的情況下，或是在不必從頭撰寫常用算法和數據結構的情況下，完成琳琅滿目的各種複雜程式。C++ 編譯器的數量不斷增加，它們所供應的語言性質不斷擴充，它們所產生的代碼質量也不斷改善。C++ 開發工具和開發環境愈來愈豐富，威力愈來愈強大，健壯（robust）的程度也愈來愈高。商業化程式庫幾乎能夠滿足各個套用領域中的編程需求。

一旦語言進入成熟期，我們對它的使用經驗也就愈來愈多，我們所需要的信息也就隨之改變了。1990 年人們想知道 C++ 是什麼東西。到了 1992 年，他們想知道如何運用它。如今 C++ 程式設計師問的問題更高級：我如何能夠設計出適應未來需求的軟體？我如何能夠改善代碼的效率而不折損正確性和易用性？我如何能夠實現語言不能直接支持的精巧功能？

這本書中我要回答這些問題，以及其他許多類似問題。

本書將告訴你如何更具實效地設計並實現 C++ 軟體：讓它行為更正確，面對異常時更健壯、更有效率、更具移植性，將語言特性發揮得更好，更優雅地調整適應，在“混合語言”開發環境中運作得更好，更容易被正確運用，更不容易被誤用。簡單地說就是如何讓軟體更好。

本書內容分為 35 個條款。每個條款都在特定主題上精簡摘要出 C++ 程式設計社區所積累的智慧型。大部分條款以準則的形式呈現，隨附的說明則闡述這條準則為什麼存在，如果不遵循會發生什麼後果，以及什麼情況下可以合理違反該準則。

所有條款被我分為數大類。某些條款關心特定的語言性質，特別是你可能少有使用經驗的一些新性質。例如條款9~15專注於exceptions（就像Tom Cargill，JackReeves，Herb Sutter 所發表的那些雜誌文章一樣）。其他條款解釋如何結合語言的不同特性以達成更高階目標。例如條款25~31描述如何限制對象的個數或誕生地點，如何根據一個以上的對象類型產生出類似虛函式的東西，如何產生smart pointers等。其他條款解決更廣泛的題目。條款16~24 專注於效率上的議題。不論哪一個條款，提供的都是與其主題相關且意義重大的做法。在 More Effective C++ 一書中你將學習到如何更實效、更精銳地使用C++。大部分C++ 教科書中對語言性質的大量描述，只能算是本書的一個背景信息而已。

這種處理方式意味著，你應該在閱讀本書之前便熟悉 C++。我假設你已了解classes（類）、保護層級（protection levels）、虛函式、非虛函式，我也假設你已通曉 templates 和 exceptions 背後的概念。我並不期望你是一位語言專家，所以涉及較罕見的 C++ 特性時，我會進一步解釋。

本書所談的C++

我在本書所談、所用的C++，是 ISO/ANSI 標準委員會於1997年11月完成的C++ 國際標準最後草案（Final Draft International Standard）。這暗示了我所使用的某些語言特性可能並不在你的編譯器（s）支持能力之列。別擔心，我認為對你而言唯一所謂的“新”特性，應該只有 templates，而 templates 如今幾乎已是各家編譯器的必備功能。我也運用 exceptions，並大量集中於條款9~15。如果你的編譯器（s）未能支持 exceptions，沒什麼大不了，這並不影響本書其他部分帶給你的好處。但是，聽我說，即使你不需要用到 exceptions，亦應閱讀條款9~15，因為那些條款（及其相關篇幅）檢驗了某些不論什麼場合下你都應該了解的主題。

我承認，就算標準委員會授意某一語言特性或是贊同某一實務做法，並非就保證該語言特性已出現在目前的編譯器上，或該實務做法已可套用於既有的開發環境上。一旦面對“標準委員會所議之理論”和“真正能夠有效運作之實務”間的矛盾，我便將兩者都加以討論，雖然我其實更重視實務。由於兩者我都討論，所以當你的編譯器（s）和C++ 標準不一致時，本書可以協助你，告訴你如何使用目前既有的架構來模擬編譯器（s）尚未支持的語言特性。而當你決定將一些原本繞道而行的解決辦法以新支持的語言特性取代時，本書亦可引導你。

注意當我說到編譯器（s）時，我使用複數。不同的編譯器對C++ 標準的滿足程度各不相同，所以我鼓勵你在至少兩種編譯器（s）平台上發展代碼。這么做可以幫助你避免不經意地依賴某個編譯器專屬的語言延伸性質，或是誤用某個編譯器對標準規格的錯誤闡釋。這也可以幫助你避免使用過度先進的編譯器技術，例如，獨家廠商才做得出的某種語言新特性。如此特性往往實現得不夠精良（臭蟲多，要不就表現得遲緩，或是兩者兼具），而且C++ 社區往往對這些特性缺乏使用經驗，無法給你套用上的忠告。雷霆萬鈞之勢固然令人興奮，但當你的目標是要產生可靠的代碼，恐怕還是步步為營（並且能夠與人合作）的好。

本書用了兩個你可能不太熟悉的C++ 性質，它們都是晚些才加入C++ 標準之中的。某些編譯器支持它們，但如果你的編譯器不支持，你可以輕易地用你所熟悉的其他性質來模擬它們。

第一個性質是bool類型，其值必為關鍵字true 或false。如果你的編譯器尚未支持 bool，有兩個方法可以模擬它。第一個方法是使用一個 global enum：

enum bool { false, true };

這允許你將參數為 bool 或 int 的不同函式加以重載（overloading）。缺點是，內建的“比較操作符（comparison operators）”如 ==，<，>=，等仍舊返回 ints。所以以下代碼的行為不如我們所預期：

void f(int);

void f(bool);

int x, y;

...

f( x < y ); // 調用 f(int)，但其實它應該調用 f(bool)。

一旦你改用真正支持 bool 的編譯器，這種 enum 近似法可能會造成程式行為的改變。

另一種做法是利用 typedef 來定義 bool，並以常量對象作為 true 和 false：

typedef int bool;

const bool false = 0;

const bool true = 1;

這種手法與傳統的 C/C++ 語義兼容。使用這種仿真法的程式，在移植到一個支持有bool 類型的編譯器平台之後，行為並不會改變。缺點則是無法在函式重載（overloading）時區分 bool 和 int。以上兩種近似法都有道理，請選擇最適合你的一種。

第二個新性質，其實是4 個轉型操作符：static_cast，const_cast，dynamic_cast和reinterpret_cast。如果你不熟悉這些轉型操作符，請翻到條款2仔細閱讀其中內容。它們不只比它們所取代的 C 舊式轉型做得更多，也更好。書中任何時候當我需要執行轉型動作，我都使用新式的轉型操作符。

C++ 擁有比語言本身更豐富的東西。是的，C++ 還有一個偉大的標準程式庫（見條款E49）。我儘可能使用標準程式庫所提供的 string 類型來取代 char* 指針，而且我也鼓勵你這么做。string objects 並不比char*-based 字元串難操作，它們的好處是可以免除你大部分的記憶體管理工作。而且如果發生 exception 的話（見條款9和10），string objects 比較不會出現 memory leaks（記憶體泄漏）問題。實現良好的string 類型甚至可和對應的 char* 比賽效率，而且可能會贏（條款29 會告訴你其中的故事）。如果你不打算使用標準的string 類型，你當然會使用類似string 的其他 classes，是吧？是的，用它，因為任何東西都比直接使用 char* 來得好。

我將儘可能使用標準程式庫提供的數據結構。這些數據結構來自StandardTemplate Library（“STL”——見條款35）。STL包含bitsets，vectors，lists，queues，stacks，maps，sets，以及更多東西，你應該儘量使用這些標準化的數據結構，不要情不自禁地想寫一個自己的版本。你的編譯器或許沒有附帶STL給你，但不要因為這樣就不使用它。感謝 Silicon Graphics 公司的熱心，你可以從 SGI STL網站下載一份免費產品，它可以和多種編譯器配合使用。

如果你目前正在使用一個內含各種算法和數據結構的程式庫，而且用得相當愉快，那么就沒必要只為了“標準”兩個字而改用 STL。然而如果你在“使用 STL”和“自行撰寫同等功能的代碼”之間可以選擇，你應該讓自己傾向使用STL。記得代碼的復用性嗎？STL（以及標準程式庫的其他組件）之中有許多代碼是十分值得重複運用的。

慣例與術語

任何時候如果我談到 inheritance（繼承），我的意思是 public inheritance（見條款E35）。如果我不是指 public inheritance，我會明確地指出。繪製繼承體系圖時，我對 base-derived 關係的描述方式，是從 derived classes往 base classes 畫箭頭。例如，下面是條款31的一張繼承體系圖。

這樣的表現方式和我在 Effective C++ 第一版（注意，不是第二版）所採用的習慣不同。現在我決定使用這種最被廣泛接受的箭頭畫法：從 derived classes 畫往base classes，而且我很高興事情終能歸於一統。此類示意圖中，抽象類（abstractclasses，例如上圖的 GameObject）被我加上陰影而具體類（concrete classes，例如上圖的 SpaceShip）未加陰影。

Inheritance（繼承）機制會引發“pointers（或 references）擁有兩個不同的類型”的議題，兩個類型分別是靜態類型（static type）和動態類型（dynamic type）。Pointer或 reference 的“靜態類型”是指其聲明時的類型，“動態類型”則由它們實際所指的對象來決定。下面是根據上圖所寫的一個例子：

GameObject *pgo = // pgo 的靜態類型是 GameObject*，

new SpaceShip; // 動態類型是 SpaceShip*。

Asteroid *pa = new Asteroid; // pa 的靜態類型是 Asteroid*，

// 動態類型也是 Asteroid*。

pgo = pa; // pgo 的靜態類型仍然（永遠）是 GameObject*，

// 至於其動態類型如今是 Asteroid*。

GameObject& rgo = *pa; // rgo 的靜態類型是 GameObject，

// 動態類型是 Asteroid。

這些例子也示範了我喜歡的一種命名方式。pgo 是一個 pointer-to-GameObject；pa 是一個 pointer-to-Asteroid；rgo 是一個 reference-to-GameObject。我常常以此方式來為 pointer 和 reference 命名。

我很喜歡兩個參數名稱：lhs 和 rhs，它們分別是“left-hand side”和“right-handside”的縮寫。為了了解這些名稱背後的基本原理，請考慮一個用來表示分數（rational numbers）的 class：

class Rational { ... };

如果我想要一個“用來比較兩個 Rational objects”的函式，我可能會這樣聲明：

bool operator==(const Rational& lhs, const Rational& rhs);

這使我得以寫出這樣的代碼：

Rational r1, r2;

...

if (r1 == r2) ...

在調用 operator== 的過程中，r1 位於“==”左側，被綁定於 lhs，r2 位於“==”右側，被綁定於 rhs。

我使用的其他縮寫名稱還包括：ctor 代表“constructor”，dtor 代表“destructor”，RTTI 代表 C++ 對 runtime type identification 的支持（在此性質中，dynamic_cast是最常被使用的一個組件）。

當你分配記憶體而沒有釋放它，你就有了memory leak（記憶體泄漏）問題。Memoryleaks 在 C 和 C++ 中都有，但是在 C++ 中，memory leaks所泄漏的還不只是記憶體，因為 C++ 會在對象被產生時，自動調用 constructors，而 constructors 本身可能亦配有資源（resources）。舉個例子，考慮以下代碼：

class Widget { ... }; // 某個 class——它是什麼並不重要。

Widget *pw = new Widget; // 動態分配一個 Widget 對象。

... // 假設 pw 一直未被刪除（deleted）。

這段代碼會泄漏記憶體，因為pw 所指的Widget 對象從未被刪除。如果Widget constructor 分配了其他資源（例如 file descriptors，semaphores，window handles，database locks），這些資源原本應該在 Widget 對象被銷毀時釋放，而現在也像記憶體一樣都泄漏掉了。為了強調在 C++ 中 memory leaks 往往也會泄漏其他資源，我在書中常以 resource leaks 一詞取代 memory leaks。

你不會在本書中看到許多 inline 函式。並不是我不喜歡 inlining，事實上我相信 inline 函式是 C++ 的一項重要性質。然而決定一個函式是否應被 inlined，條件十分複雜、敏感，而且與平台有關（見條款E33）。所以我儘量避免 inlining，除非其中有個關鍵點非使用 inlining 不可。當你在本書中看到一個 non-inline 函式，並不意味我認為把它聲明為 inline 是個壞主意，而只是說，它“是否為 inline”與當時討論的主題無關。

有一些傳統的 C++ 性質已明確地被標準委員會排除。這樣的性質被列於語言的最後撤除名單，因為新性質已經加入，取代那些傳統性質的原本工作，而且做得更好。這本書中我會找出被撤除的性質，並說明其取代者。你應該避免使用被撤除的性質，但是過度在意倒也不必，因為編譯器廠商為了挽留其客戶，會盡力保存向下兼容性，所以那些被撤除的性質大約還會存活好多年。

所謂 client，是指你所寫代碼的客戶。或許是某些人（程式設計師），或許是某些物（classes 或 functions）。舉個例子，如果你寫了一個 Date class（用來表現生日、最後期限、耶穌再次降臨日等），任何使用了這個 class 的人，便是你的 client。任何一段使用了 Date class 的代碼，也是你的 clients。Clients 是重要的，事實上

clients 是遊戲的主角。如果沒有人使用你寫的軟體，你又何必寫它呢？你會發現我很在意如何讓 clients 更輕鬆，通常這會導致你的行事更困難，因為好的軟體“以客為尊”。如果你譏笑我太過濫情，不妨反躬自省一下。你曾經使用過自己寫的 classes或 functions 嗎？如果是，你就是你自己的 client，所以讓 clients 更輕鬆，其實就是讓自己更輕鬆，利人利己。

當我討論class templates或function templates，以及由它們所產生出來的 classes或 functions 時，請容我保留偷懶的權利，不一一寫出 templates 和其 instantiations（實例）之間的差異。舉個例子，如果 Array 是個 class template，有個類型參數T，我可能會以 Array 代表此 template 的某個特定實例（instantiation）——雖然其實Array<T> 才是正式的 class 名稱。同樣道理，如果swap 是個 function template，有個類型參數 T，我可能會以 swap 而非 swap<T> 表示其實例。如果這樣的簡短表示法在當時情況下不夠清楚，我便會在表示 template 實例時加上 template參數。

臭蟲報告，意見提供，內容更新

我盡力讓這本書技術精準、可讀性高，而且有用，但是我知道一定仍有改善空間。如果你發現任何錯誤——技術性的、語言上的、錯別字，或任何其他問題——請告訴我，我會試著在本書重印時修正。如果你是第一位告訴我的人，我會很高興將你的大名記錄到本書致謝文（acknowledgments）內。如果你有改善建議，我也非常歡迎。

我將繼續收集 C++ 程式設計的實效準則。如果你有任何這方面的想法並願意與我分享，我會十分高興。請將你的建議、你的見解、你的批評，以及你的臭蟲報告，寄至：

Scott Meyers

c/o Editor-in-Chief, Corporate and Professional Publishing

Addison-Wesley Publishing Company

1 Jacob Way

Reading, MA 01867

U. S. A.

我整理了一份本書第一次印刷以來的修訂記錄，其中包括錯誤修正、文字修潤，以及技術更新。你可以從本書網站取得這份記錄及與本書相關的其他信息。你也可以通過 anonymous FTP，從 的 cp/mec++ 目錄中取得它。如果你希望擁有這份數據，但又無法上網，請寄申請函到上述地址，我會郵寄一份給你。

這篇序文夠長的了，讓我們開始正題吧。

目錄

譯序（侯捷）

導讀（Introduction）

基礎議題（Basics）

條款1：仔細區別 pointers 和 references

Distinguish between pointers and references.

條款2：最好使用 C++ 轉型操作符

Prefer C++-style casts.

條款3：絕對不要以多態（polymorphically）方式處理數組

Never treat arrays polymorphically.

條款4：非必要不提供 default constructor

Avoid gratuitous default constructors.

操作符（Operators）

條款5：對定製的“類型轉換函式”保持警覺

Be wary of user-defined conversion functions.

條款6：區別 increment/decrement 操作符的

前置（prefix）和後置（postfix）形式

Distinguish between prefix and postfix forms of increment

and decrement operators.

條款7：千萬不要重載&&，||和, 操作符

Never overload &&, ||, or ,.

條款8：了解各種不同意義的 new 和 delete

Understand the different meanings of new and delete

異常（Exceptions）

條款9：利用 destructors 避免泄漏資源

Use destructors to prevent resource leaks.

條款10：在 constructors 內阻止資源泄漏（resource leak）

Prevent resource leaks in constructors.

條款11：禁止異常（exceptions）流出 destructors 之外

Prevent exceptions from leaving destructors.

條款12：了解“拋出一個 exception”與“傳遞一個參數”

或“調用一個虛函式”之間的差異

Understand how throwing an exception differs from

passing a parameter or calling a virtual function.

條款13：以 by reference 方式捕捉 exceptions

Catch exceptions by reference.

條款14：明智運用 exception specifications

Use exception specifications judiciously.

條款15：了解異常處理（exception handling）的成本

Understand the costs of exception handling.

效率（Efficiency）

條款16：謹記 80-20 法則

Remember the 80-20 rule.

條款17：考慮使用 lazy evaluation（緩式評估）

Consider using lazy evaluation.

條款18：分期攤還預期的計算成本

Amortize the cost of expected computations.

條款19：了解臨時對象的來源

Understand the origin of temporary objects.

條款20：協助完成“返回值最佳化（RVO）”

Facilitate the return value optimization.

條款21：利用重載技術（overload）避免隱式類型轉換（implict type conversions）

Overload to avoid implicit type conversions.

條款22：考慮以操作符複合形式（op=）取代其獨身形式（op）

Consider using op= instead of stand-alone op.

條款23：考慮使用其他程式庫

Consider alternative libraries.

條款24：了解 virtual functions、multiple inheritance、virtual base classes、

runtime type identification 的成本

Understand the costs of virtual functions, multiple inheritance,

virtual base classes, and RTTI.

技術（Techniques, Idioms, Patterns）

條款25：將 constructor 和 non-member functions 虛化

Virtualizing constructors and non-member functions.

條款26：限制某個 class 所能產生的對象數量

Limiting the number of objects of a class.

條款27：要求（或禁止）對象產生於 heap 之中

Requiring or prohibiting heap-based objects.

條款28：Smart Pointers（智慧型指針）

條款29：Reference counting（引用計數）

條款30：Proxy classes（替身類、代理類）

條款31：讓函式根據一個以上的對象類型來決定如何虛化

Making functions virtual with respect to more than one object.

雜項討論（Miscellany）

條款32：在未來時態下發展程式

Program in the future tense.

條款33：將非尾端類（non-leaf classes）設計為

抽象類（abstract classes）

Make non-leaf classes abstract.

條款34：如何在同一個程式中結合 C++ 和 C

Understand how to combine C++ and C in the same program.

條款35：讓自己習慣於標準 C++ 語言

Familiarize yourself with the language standard.

推薦讀物

auto_ptr 實現代碼

索引（一）（General Index）

索引（二）（Index of Example Classes，Functions，and Templtes）