C++之父Bjarne Stroustrup 寫的 The C++ Programming Language (Special Edition) 中各章後
面的忠告。
第1 章致讀者
[1] 在編寫程序時，你是在爲你針對某個問題的解決方案中的思想建立起一種具體表示。讓程序的結構儘可能地直接反映這些思想。
[a] 如果你能把“它”看成一個獨立的概念，就把它做成一個類。
[b] 如果你能把“它”看成一個獨立地實體，就把它做成某個類的一個對象。
[c] 如果兩個類有共同的界面，將此界面做成一個抽象類。
[d] 如果兩個類的實現有某些顯著的共同東西，靜這些共性做成一個基類。
[e] 如果一個類是一種對象的容器，將它做成一個模板。
[f] 如果一個函數實現對某容器的一個算法，將它實現爲對一族容器可用的模板函數。
[g] 如果一組類、模板等互相之間有邏輯關係，將它們放進一個名字空間力。
[2] 在你定義一個並不是實現某個像矩陣或複數這樣的數學對象的類時，或者定義一個低層的類型如鏈表的時候：
[a] 不要使用全局數據（使用成員）。
[b] 不要使用全局函數。
[c] 不要使用公用數據成員。
[d] 不要使用友元，除非爲了避免[a]或[c]。
[e] 不要在一個類裏面放“類型域”；採用虛函數。
[f] 不要使用內聯函數，除非作爲效果顯著的優化。
第2 章C++概覽
[1] 不用害怕，一切都會隨着時間的推移而逐漸明朗起來。
[2] 你並不需要在知道了C++地所有細節之後才能寫出好的C++程序。
[3] 請特別關注程序設計技術，而不是各種語言特徵。
第3 章標準庫概念
[1] 不要像重新發明車輪那樣企圖做每件事；去使用庫。
[2] 不要相信奇蹟；要理解你的庫能做什麼，它們如何做，它們做時需要多大代價。
[3] 當你遇到一個選擇時，應該優先選擇標準庫而不是其他的庫。
[4] 不要認爲標準庫對於任何事情都是最理想的。
[5] 切記#include 你所用到的功能的頭文件。
[6] 記住，標準庫的功能定義在名字空間std 中。
[7] 請用string，而不是char*。
[8] 如果懷疑，就用一個檢查區間範圍的向量。
[9] vector<T>、list<T>和map<key, value>都比T[]好。
[10] 如果要向一個容器中添加一個元素，用push_back()或back_insert()。
[11] 採用對vector 的push_back()，而不是realloc()。
[12] 在main()中捕捉公共的異常。
第4 章類型和聲明
[1] 保持較小的作用域。
[2] 不要在一個作用域和它外圍的作用域裏採用同樣的名字。
[3] 在一個聲明中（只）聲明一個名字。
[4] 讓常用的和局部的名字比較短，讓不常用的和全局的名字比較長。
[5] 避免看起來類似的名字。
[6] 維持某種統一的命名風格。
[7] 仔細選擇名字，反映其意義而不是反映實現方式。
[8] 如果所用的內部類型表示某種可能變化的值，請用typdef 爲它定義一個有意義的名字。
[9] 用typedef 爲類型定義同義詞，用枚舉或類去定義新類型。
[10] 切記每個聲明中都必須描述一個類型（沒有隱式的int ）。
[11] 避免有關字符值的不必要的假設。
[12] 避免有關整數大小的不必要假設。
[13] 避免有關浮點類型表示範圍的不必要假設。
[14] 優先使用普通的int 而不是short int 或者long int 。
[15] 優先使用double 而不是float 或者long double。
[16] 優先使用普通的char 而不是signed char 或者unsigned char。
[17] 避免做出有關對象大小的不必要假設。
[18] 避免無符號算術。
[19] 應該帶着疑問去看待從signed 到unsigned，或者從unsigned 到singed 的轉換。
[20] 應該帶着疑問去看待從浮點到整數的轉換。
[21] 應該帶着疑問其看待向較小類型的轉換，如將int 轉換到char。
第5 章指針、數組和結構
[1] 避免非平凡的指針算術。
[2] 當心，不要超出函數的界限去寫。
[3] 儘量使用0 而不是NULL。
[4] 儘量使用vector 和valarrray 而不是內部（C 風格）的數組。
[5] 儘量使用string 而不是以0 結尾的char 數組。
[6] 儘量少使用普通的引用參數。
[7] 避免void*，除了在某些低級代理。
[8] 避免在代碼中使用非平凡的文字量（“神祕的數”）。相反，應該定義和使用各種符號常量。
第6 章表達式和語句
[1] 應儘量可能使用標準庫，而不是其他的庫和“手工打造的代碼”。
[2] 避免過於複雜的表達式。
[3] 如果對運算符的優先級有疑問，加括號。
[4] 避免顯式類型轉換。
[5] 若必須做顯式類型轉換，提倡使用特殊強制運算符，而不是C 風格的強制。
[6] 只對定義良好的構造使用T(e)記法。
[7] 避免帶有無定義求值順序的表達式。
[8] 避免goto。
[9] 避免do 語句。
[10] 在你已經有了去初始化某個變量的值之前，不要去聲明它。
[11] 式註釋簡潔、清晰、有意義。
[12] 保持一致的縮進編排風格。
[13] 傾向於去定義一個成員函數operator new()去取代全局的operator new()。
[14] 在讀輸入的時候，總應考慮病態形式的輸入。
第7 章函數
[1] 質疑那些非const 的引用參數；如果你想要一個函數去修改其參數，請使用指針或者返回值。
[2] 當你需要儘可能減少參數複製時，應該使用const 引用參數。
[3] 廣泛而一致地使用const。
[4] 避免宏。
[5] 避免不確定數目的參數。
[6] 不要返回局部變量的指針或者引用。
[7] 當一些函數對不同的類型執行概念上相同的工作時，請使用重載。
[8] 在各種整數上重載時，通過提供函數去消除常見的歧義性。
[9] 在考慮使用指向函數的指針時，請考慮虛函數或模板是不是更好的選擇。
[10] 如果你必須使用宏，請使用帶有許多大寫字母的醜陋的名字。
第8 章名字空間和異常
[1] 用名字空間表示邏輯結構。
[2] 將每個非局部的名字放入某個名字空間裏，除了main()之外。
[3] 名字空間的設計應該讓你能很方便地使用它，而又不會意外地訪問了其他的無關名字空間。
[4] 避免對名字空間使用很短的名字。
[5] 如果需要，通過名字空間別名去緩和和長名字空間的影響。
[6] 避免給你的名字空間的用戶添加太大的記法負擔。
[7] 在定義名字空間的成員時使用namespace::member 的形式。
[8] 只在轉換時，或者在局部作用域裏，才用using namespace。
[9] 利用異常去鬆弛“錯誤”處理代碼和正常處理代碼之間的聯繫。
[10] 採用用戶定義類型作爲異常，不用內部類型。
[11] 當局部控制結構足以應付問題，不要使用異常。
第9 章源文件和程序
[1] 利用頭文件去表示界面和強調邏輯結構。
[2] 用#include 將頭文件包含到實現有關功能的源文件裏。
[3] 不要在不同編譯單位裏定義具有同樣名字，意義類似但又不同的全局變量。
[4] 避免在頭文件裏定義非inline 函數。
[5] 只在全局作用域或名字空間裏使用#include。
[6] 只用#include 包含完整的定義。
[7] 使用包含保護符。
[8] 用#include 將C 頭文件包含到名字空間裏，以避免全局名字。
[9] 將頭文件做成自給自足的。
[10] 區分用戶界面和實現界面。
[11] 區分一般用戶界面和專家用戶界面。
[12] 在有意向用於非C++程序組成部分的代碼中，應避免需要運行時初始化的非局部對象。
第10 章類
[1] 用類表示概念。
[2] 只將public 數據（struct）用在它實際殺過那僅僅時數據，而且對於這些數據成員並不存在不變式的地方。
[3] 一個具體類型屬於最簡單的類。如果有用的話，就應該儘可能使用具體類型，而不要採用更復雜的，也不要用簡單的數據結構。
[4] 只將那些需要直接訪問類的表示的函數作爲成員函數。
[5] 採用名字空間，使類與其協助函數之間的關係更明確。
[6] 將那些不修改對象值的成員函數做成const 成員函數。
[7] 將那些需要訪問類的表示，但無須針對特定對象調用的成員函數做成static 成員函數。
[8] 通過構造函數建立起類的不變式。
[9] 如果構造函數申請某種資源，析構函數就應該釋放一資源。
[10] 如果在一個類裏有指針成員，它就要有複製操作（包括複製構造函數和複製賦值）。
[11] 如果在一個類裏有引用成員，它就可能需要有複製操作（包括複製構造函數和複製賦值）。
[12] 如果一個類需要複製操作或析構函數，它多半還需要有構造函數、析構函數、複製賦值函數和複製構造函數。
[13] 在複製賦值函數裏需要檢查自我賦值。
[14] 在寫複製構造函數時，請小心地複製每個需要複製的元素（當心默認的初始式）。
[15] 在向某個類中添加新成員函數時，一定要仔細檢查，看是否存在需要更新的用戶定義構造函數，以使它能夠初始化新成員。
[16] 在類聲明中需要定義整型常量時，請使用枚舉。
[17] 在構造全局的和名字空間的對象時，應避免順序依賴性。
[18] 用第一次開關去緩和順序依賴性問題。
[19] 請記住，臨時對象將在建立它們的那個完整表達式結束時銷燬。
第11 章運算符重載
[1] 定義運算符主要是爲了模仿習慣使用方式。
[2] 對於大型運算對象，請使用const 引用參數類型。
[3] 對於大型的結果，請考慮優化返回方式。
[4] 如果默認複製操作對一個類和合適，最好是直接用它。
[5] 如果默認複製操作對一個類不和合適，重新定義它，或者禁止它。
[6] 對於需要訪問表示的操作，優先考慮作爲成員函數而不是作爲非成員函數。
[7] 對於不訪問表示的操作，優先考慮作爲非成員函數而不是作爲成員函數。
[8] 用名字空間將協助函數與“它們的”類關聯起來。
[9] 對於對稱的運算符采用非成員函數。
[10] 用()作爲多維數組的下標。
[11] 將只有一個“大小參數”的構造函數做成explicit。
[12] 對於非特殊的使用，最好是用標準string 而不是你自己的練習。
[13] 要注意引進隱式轉換的問題。
[14] 用成員函數表達那些需要左值作爲其左運算對象的運算符。
第12 章派生類
[1] 避免類型域。
[2] 用指針和引用避免切割問題。
[3] 用抽象類將設計的中心集中到提供清晰的界面方面。
[4] 用抽象類是界面最小化。
[5] 用抽象類從界面中排除實現細節。
[6] 用虛函數是新的實現能夠添加進來，又不會影響用戶代碼。
[7] 用抽象類去儘可能減少用戶代碼的重新編譯。
[8] 用抽象類是不同的實現能夠共存。
[9] 一個有虛函數的類應該有一個虛析構函數。
[10] 抽象類通常不需要構造函數。
[11] 讓不同概念的表示也不同。
第13 章模板
[1] 用模板描述需要使用到許多參數類型上去的算法。
[2] 用模板表述容器。
[3] 爲指針的容器提供專門化，以減小代碼規模。
[4] 總是在專門化之前聲明模板的一般形式。
[5] 在專門化的使用之前先聲明它。
[6] 儘量減少模板定義對於實例化環境的依賴性。
[7] 定義你所聲明的每一個專門化。
[8] 考慮一個模板是否需要有針對C 風格字符串和數組的專門化。
[9] 用表述策略的對象進行參數化。
[10] 用專門化和重載爲同一概念的針對不同類型的實現提供統一界面。
[11] 爲簡單情況提供簡單界面，用重載和默認參數去表述不常見的情況。
[12] 在修改爲通用模板之前，在具體實例上排除程序錯誤。
[13] 如果模板定義需要在其他編譯單位裏訪問，請記住寫export。
[14] 對大模板和帶有非平凡環境依賴性的模板，應採用分開編譯的方式。
[15] 用模板表示轉換，但要非常小心地定義這些轉換。
[16] 如果需要，用constraint()成員函數給模板的實參增加限制。
[17] 通過顯式實例化減少編譯和連接時間。
[18] 如果運行時的效率非常重要，那麼最好用模板而不是派生類。
[19] 如果增加各種變形而又不重新編譯是很重要的，最好用派生類而不是模板。
[20] 如果無法定義公共的基類，最好用模板而不是派生類。
[21] 當有兼容性約束的內部類型和結構非常重要時，最好用模板而不是派生類。
第14 章異常處理
[1] 用異常做錯誤處理。
[2] 當更局部的控制機構足以應付時，不要使用異常。
[3] 採用“資源申請即初始化”技術去管理資源。
[4] 並不是美國程序都要求具有異常時的安全性。
[5] 才用“資源申請即初始化”技術和異常處理器去維持不變式。
[6] 儘量少用try 塊，用“資源申請即初始化”技術，而不是顯式的處理器代碼。
[7] 並不是美國函數都需要處理每個可能的錯誤。
[8] 在構造函數裏通過拋出異常指明出現失敗。
[9] 在從賦值中拋出異常之前，式操作對象處於合法狀態。
[10] 避免從析構函數裏拋出異常。
[11] 讓main()捕捉並報告所有的異常。
[12] 使正常處理代碼和錯誤處理代碼相互分離。
[13] 在構造函數裏拋出異常之前，應保證釋放在此構造函數裏申請的所有資源。
[14] 使資源管理具有層次性。
[15] 對於主要界面使用異常描述。
[16] 當心通過new 分配的內存在發生異常時沒有釋放，並由此而導致存儲的流失。
[17] 如果一函數可能拋出某個異常，就應該假定它一定會拋出這個異常。
[18] 不要假定所有異常都時由excepion 類派生出來的。
[19] 庫不應該單方面終止程序。相反，應該拋出異常，讓調用者去做決定。
[20] 庫不應該生成面向最終用戶的錯誤信息。相反，它應該拋出異常，讓調用者去做決定。
[21] 在設計的前期開發出一種錯誤處理策略。
第15 章類層次結構
[1] 利用常規的多重繼承表述特徵的合併。
[2] 利用多重繼承完成實現細節與界面分離。
[3] 用virtual 基類表達在類層次結構裏對某些類（不是全部類）共同的東西。
[4] 避免顯式的類型轉換（強制）。
[5] 在不可避免地需要漫遊類層次結構的地方，使用dynamic_cast。
[6] 儘量使用dynamic_cast 而不是typeid。
[7] 儘量使用private 而不是protected。
[8] 不要聲明protected 數據成員。
[9] 如果某個類定義了operator delete()，它也應該有虛析構函數。
[10] 在構造和析構期間不要調用虛函數。
[11] 儘量少用爲解析成員名而寫的顯式限定詞，最好時在覆蓋函數裏用它。
第16 章庫組織和容器
[1] 利用標準庫功能，以維持可移植性。
[2] 決不要另行定義標準庫的功能。
[3] 決不要認爲標準庫比什麼都好。
[4] 在定義一種新功能時，應考慮它是否能納入標準庫所提供的框架中。
[5] 記住標準庫功能都定義在名字空間std 裏。
[6] 通過包含保準卡頭文件聲明其功能，不要自己另行顯式聲明。
[7] 利用後續抽象的優點。
[8] 避免肥大的界面。
[9] 與自己寫按照反向順序的顯式循環相比，最好是寫利用反向迭代器的算法。
[10] 用base()從reverse_iterator 抽取出iterator。
[11] 通過引用傳遞容器。
[12] 用迭代器類型，如list<char>::iterator，而不要採用索引容器元素的指針。
[13] 在不需要修改容器元素時，使用const 迭代器。
[14] 如果希望檢查訪問範圍，請（直接或間接）使用at()。
[15] 多用容器和push_back()或resize()，少用數組和realloc().
[16] vector 改變大小之後，不要使用指向其中的迭代器。
[17] 利用reserve()避免使迭代器非法。
[18] 在需要的時候，reserve()可以使執行情況更容易預期。
第17 章標準庫容器
[1] 如果要用容器，首先考慮用vector。
[2] 瞭解你經常使用的每個操作的代價（複雜性，大O 度量）。
[3] 容器的界面、實現和表示使不同的概念，不要混淆。
[4] 你可以依據多種不同準則去排序和搜索。
[5] 不要用C 風格的字符串作爲關鍵碼，除非你提供了一種適當的比較準則。
[6] 你可以定義這樣的比較準則，使等價的但是不相同的關鍵碼值映射到同一個關鍵碼。
[7] 在插入和刪除元素時，最好時使用序列末端的操作（back 操作）。
[8] 當你需要在容器的前端或中間做許多插入和刪除時，請用list。
[9] 當你主要通過關鍵碼訪問元素時，請用map 或multimap。
[10] 儘量用最小的操作集合，以取得最大的靈活性。
[11] 如果要保持元素的順序性，選用map 而不是hash_map。
[12] 如果查找速度極其重要，選hash_map 而不是map。
[13] 如果無法對元素定義小於操作時，選hash_map 而不是map。
[14] 當你需要檢查某個關鍵碼是否在關聯容器裏的時候，用find()。
[15] 用equal_range()在關聯容器裏找出所有具有給定關鍵碼的所有元素。
[16] 當具有同樣關鍵碼的多個值需要保持順序時，用multimap。
[17] 當關鍵碼本身就是你需要保存的值時，用set 或multiset。
第18 章算法和函數對象
[1] 多用算法，少用循環。
[2] 在寫循環時，考慮是否能將它表述爲一個通用的算法。
[3] 常規性地重溫算法集合，看卡是不是能將新應用變得更明晰。
[4] 保證一對迭代器參數確實表述了一個序列。
[5] 設計時應該讓使用最頻繁的操作時簡單而安全的。
[6] 吧測試表述成能夠作爲謂詞使用的形式。
[7] 切記謂詞是函數和對象，不是類型。
[8] 你可以用約束器從二元謂詞做出一元謂詞。
[9] 利用mem_fun()和mem_fun_ref()將算法應用於容器。
[10] 當你需要將一個參數約束到一個函數上時，用ptr_fun()。
[11] 切記srrcmp()用0 表示“相等”，與==不同。
[12] 僅在沒有更特殊的算法時，才使用for_each()和tranform()。
[13] 利用謂詞，以便能一各種比較準則和相等準則使用算法。
[14] 利用謂詞和其他函數對象，以使標準算法能用於表示範圍廣泛的意義。
[15] 運算符<和==在指針上的默認意義很少適用於標準算法。
[16] 算法並不直接爲它們的參數序列增加或減少元素。
[17] 應保證用於同一個序列的小於和相等謂詞相互匹配。
[18] 有時排好序的序列用起來更有效且優雅。
[19] 僅爲兼容性而使用qsort()和bsearch()。
第19 章迭代器和分配器
[1] 在寫一個算法時，設法確定需要用哪種迭代器才能提供可接受的效率，並（只）使用這種迭代器所支持的操作符去表述算法。
[2] 當給定的迭代器參數提供了多於算法所需的最小支持時，請通過重載爲該算法提供效率更高的實現。
[3] 利用istream_traits 爲不同迭代器類別描述適當的算法。
[4] 記住在istream_iterator 和ostream_iterator 的訪問之前使用++。
[5] 用插入器避免容器溢出。
[6] 在排錯時使用額外的檢查，後面只在必須時才刪除這些檢查。
[7] 多用++p，少用p++。
[8] 使用未初始化的存儲去改善那些擴展數據結構的算法性能。
[9] 使用臨時緩衝區去改善需要臨時數據結構的算法的性能。
[10] 在寫自己的分配器之前三思。
[11] 避免malloc()、free()、realloc()等。
[12] 你可以通過爲rebind 所用的技術去模擬對模板的typedef。
第20 章串
[1] 儘量使用string 操作，少用C 風格字符串函數。
[2] 用string 作爲變量或者成員，不作爲基類。
[3] 你可以將string 作爲參數值或者返回值，讓系統去關心存儲管理問題。
[4] 當你希望做範圍檢查時，請用at()而不是迭代器或者[]。
[5] 當你希望優化速度時，請用迭代器或[]而不是at()。
[6] 直接或者間接地使用substr()去讀字子串，用replace()去寫子串。
[7] 用find()操作在string 裏確定值的位置（而不是寫一個顯式的循環）。
[8] 在你需要高效率地添加字符時，請在string 的後面附加。
[9] 在沒有極端時間要求情況下用string 作爲字符輸入的目標。
[10] 用string::npos 表示“sring 的剩餘部分”。
[11] 如果必要，就採用低級操作去實現極度頻繁使用的strng（而不是到處用低級數據結構）。
[12] 如果你使用string，請在某些地方捕捉length_error 和out_of_rang 異常、
[13] 小心，不要將帶值0 的char*傳遞給字符串函數。
[14] 只是到必須做的時候，（再）用c_str()產生string 的C 風格表示。
[15] 當你需要知道字符串的類別時，用isalpha()、isdigit()等函數，不要自己去寫對字符值的檢測。
第21 章流
[1] 在爲用戶定義類型的值定義<<和>>時，應該採用意義清晰的正文表達形式。
[2] 在打印包含低優先級運算符的表達式時需要用括號。
[3] 在添加新的<<和>>運算符時，你不必修改istream 或ostream。
[4] 你可以定義函數，時其能基於第二個（或更後面的）參數，具有像virtual 函數那樣的行爲。
[5] 切記，按默認約定>>跳過所有空格。
[6] 使用低級輸入函數（如get()和read()）主要是爲了實現高級輸入函數。
[7] 在使用get()、getline()和read()時留心其終止準則。
[8] 在控制I/O 時，儘量採用操控符，少用狀態標誌。
[9] （只）用異常去捕捉罕見的I/O 錯誤。
[10] 聯結用於交互式I/O 的流。
[11] 使用哨位將許多函數的入口和出口代碼集中到一個地方。
[12] 在無參數操控符最後不要寫括號。
[13] 使用標準操控符式應記住寫#include <iomanip>。
[14] 你可以通過定義一個簡單函數對象得到三元運算符的效果（和效率）。
[15] 切記，width 描述只應用於隨後的一個I/O 操作。
[16] 切記precision 描述只對所後所的浮點數輸出操作有效。
[17] 用字符串流做內存裏的格式化。
[18] 你可以描述一個文件流的模式。
[19] 在擴充I/O 系統時，應該清楚地區分格式化（iostream）和緩衝（streambuf）。
[20] 將傳輸值的非標準方式實現爲流緩衝。
[21] 將格式化值的非標準方式實現爲流操作。
[22] 你可以利用一對函數隔離和封裝其對用戶定義代碼的調用。
[23] 你可以在讀入之前用in_avail()去確定輸入操作是否會被阻塞。
[24] 劃分清楚需要高效的簡單操作和實現某種策略的操作（將前者做成inline，將後者做成virtual）。
[25] 用locale 將“文化差異”局部化。
[26] 用sync_with_stdio(x)去混合C 風格和C++風格的I/O，或者離解C 風格和C++風格的I/O。
[27] 當心C 風格I/O 的類型錯誤。
第22 章數值
[1] 數值問題常常和微妙。如果你對數值問題的數學方面不是100%有把握，請去找專家或者做試驗。
[2] 用numberic_limits 去確定內部類型的性質。
[3] 爲用戶定義的標量類型描述numberic_limits。
[4] 如果運行時效率比對於操作和元素的靈活性更重要的話，那麼請用valarray 去做數值計算。
[5] 用切割表述在數組的一部分上的操作，而不是用循環。
[6] 利用組合器，通過清除臨時量和更好的算法來獲得效率。
[7] 用std::complex 做複數算術。
[8] 你可以把使用complex 類的老代碼通過一個typedef 轉爲用str::complex 模板。
[9] 在寫循環從一個表出發計算某個值之前，先考慮一下accumulate()、inner_produce()、partial_sum()和adjacent_difference()。
[10] 最好使用具有特定分佈的隨機數，少直接用rand()。
[11] 注意是你的隨機數充分隨機。
第23 章開發和設計
[1] 知道你試圖達到什麼目的。
[2] 心中牢記軟件開發是一項人的活動。
[3] 用類比來證明是有意的欺騙。
[4] 保持一個特定的實實在在的目標。
[5] 不要試圖用技術方式去解決社會問題。
[6] 在設計和對待人員方面都應該有長期考慮。
[7] 對於什麼程序在編碼之前先行設計是有意義的，在程序規模上並沒有下限。
[8] 設計過程應鼓勵反饋。
[9] 不要將做事情都當做取得了進展。
[10] 不要推廣到超出了所需要的、你已有直接經驗的和已經測試過的東西。
[11] 將概念表述爲類。
[12] 系統裏也存在一些不應該用類表述的性質。
[13] 將概念間的層次關係用類層次結構表示。
[14] 主動到應用和實現中去尋找概念間的共性，將由此得到的一般性概念表示爲基類。
[15] 在其他領域中的分類方式未必適合作爲應用中的繼承模型的分類方式。
[16] 基於行爲和不變式設計類層次結構。
[17] 考慮用例。
[18] 考慮用CRC 卡。
[19] 用現存系統作爲模型、靈感的源泉和出發點。
[20] 意識到視覺圖形工程的重要性。
[21] 在原型成爲負擔時就拋棄它。
[22] 爲變化而設計，將注意力集中到靈活性、可擴展性、可移植性和重用。
[23] 將注意力集中到組件設計。
[24] 讓每個界面代表在一個抽象層次中的一個概念。
[25] 面向變化進行設計，以求得穩定性。
[26] 通過將廣泛頻繁使用的界面做得最小、最一般和抽象來使設計穩定。
[27] 保持儘可能小，不爲“特殊需要”增加新特徵。
[28] 總考慮類的其他表示方式。如果不可能有其他方式，這個類可能就沒有代表某個清晰的概念。
[29] 反覆評審、精化設計和實現。
[30] 採用那些能用於調試，用於分析問題、設計和實現的最好工具。
[31] 儘早、儘可能頻繁地進行試驗、分析和測試。
[32] 不要忘記效率。
[33] 保持某種適合項目規模的規範性水平。
[34] 保證有人負責項目的整體設計。
[35] 爲可重用組件做文檔、推介和提供支持。
[36] 將目標與細節一起寫進文檔裏。
[37] 將爲新開發者提供的教許材料作爲文檔的一部分。
[38] 鼓勵設計、庫和類的重用，並給予回報。
第24 章設計和編程
[1] 應該向數據抽象和麪向對象設計的方向發展。
[2] （僅僅）根據需要去使用C++的特徵和技術。
[3] 設計應與編程風格相互匹配。
[4] 將類/概念作爲設計中最基本的關注點，而不是功能/處理。
[5] 用類表示概念。
[6] 用繼承（僅僅）表示概念間的層次結構關係。
[7] 利用應用層靜態類型的方式給出有關界面的更強的保證。
[8] 使用程序生成器和直接界面操作工具去完成定義良好的工作。
[9] 不要去使用那些與任何通用程序設計語言之間都沒有清晰界面的程序生成器或者直接界面操作工具。
[10] 保存不同層次的抽象相互分離。
[11] 關注組件設計。
[12] 保證虛函數有定義良好的意義，每個覆蓋函數都實現預期行爲。
[13] 公用界面表示的是“是一個”關係。
[14] 成員表示的是“有一個”關係。
[15] 在表示簡單包容時最好用直接成員，不用指向單獨分配的對象的指針。
[16] 設法保證使用依賴關係爲易理解的，儘可能不出現循環，而且最小。
[17] 對於所有的類，定義好不變式。
[18] 顯式地將前條件、後條件和其他斷言表述爲斷言（可能使用Assert()）。
[19] 定義的界面應該只暴露初儘可能少的信息。
[20] 儘可能減少一個界面對其他界面的依賴性。
[21] 保持界面爲強類型的。
[22] 利用應用層的類型來表述界面。
[23] 將界面表述得使請求可以傳遞給遠程得服務器。
[24] 避免肥大的界面。
[25] 儘可能地使用private 數據和成員函數。
[26] 用protected/private 區分開派生類的設計者與一般用戶間的不同需要。
[27] 使用模板去做通用型程序設計。
[28] 使用模板去做算法策略的參數化。
[29] 如果需要在編譯時做類型解析，情使用模板。
[30] 如果需要在運行時做類型解析，請使用層次結構。
第25 章類的作用
[1] 應該對一個類的使用方式做出有意識的決策（作爲設計師或者作爲用戶）。
[2] 應注意到涉及不同種類的類之間的權衡問題。
[3] 用具體類型去表示簡單的獨立概念。
[4] 用具體類型去表示那些最佳效果及其關鍵的概念。
[5] 不要從具體類派生。
[6] 用抽象類去表示那些對象的表示可能變化的界面。
[7] 用抽象類去表示那些可能出現多種對象表示共存情況的界面。
[8] 用抽象類去表示現存類型的新界面。
[9] 當類似概念共享許多實現細節時，應該使用結點類。
[10] 用結點類去逐步擴充一個實現。
[11] 用運行時類型識別從對象獲取界面。
[12] 用類去表示具有與之關聯的狀態信息的動作。
[13] 用類去表示需要存儲、傳遞或者延遲執行的動作。
[14] 利用界面類去爲某種新的用法而調整一個類（不修改這個類）。
[15] 利用界面類增加檢查。
[16] 利用句柄去避免直接使用指針和引用。
[17] 利用句柄去管理共享的表示。
[18] 在那些能預先定義控制結構的應用領域中使用應用框架。
附錄B
[1] 要學習C++，應該使用你可以得到的標準C++的最新的和完全的實現。
[2] C 和C++的公共子集並不是學習C++時最好的開始子集。
[3] 對於產品代碼，請記住並不是每個C++實現都是完全的最新的。在產品代碼中使用某個新特徵之前應先做試驗，寫一個小程序，測試你計劃使用的實現與標準的相符情況和性能。
[4] 避免被貶斥的特徵，例如全局的static；還應避免C 風格的強制。
[5]"隱含的int"已禁止，因此請明確描述每個函數、變量、const 等的類型。
[6] 在將C 程序轉爲C++程序時，首先保證函數聲明（原型）和標準頭文件的一致使用。
[7] 在將C 程序轉爲C++程序時，對以C++關鍵字爲名的變量重新命名。
[8] 在將C 程序轉爲C++程序時，將malloc()的結果強制到適當類型，或者將malloc()的所有使用都改爲new。
[9] 在將malloc()和free()轉爲new 和delete 時，請考慮用vector、push_back()和reserve()而不是realloc()。
[10] 在將C 程序轉爲C++程序時，記住這裏沒有從int 到枚舉的隱式轉換；如果需要，請用顯式轉換。
[11] 在名字空間std 裏定義的功能都定義在無後綴的頭文件裏（例如，std::cout 聲明在裏）。早些的實現將標準庫功能定義在全局空間裏，聲明在帶.h 後綴的頭文件裏（例如，std::cout聲明在裏）。
[12] 如果老的代碼檢測new 的結果是否爲0，那麼必須將它修改爲捕捉bad_alloc 或者使用new(nothrow)。
[13] 如果你用的實現不支持默認模板參數，請顯式提供參數；用typedef 可以避免重複寫模板參數（類似於string 的typedef 使你無須寫basic_string, allocator >）。
[14] 用得到std::string（裏保存的是C 風格的串函數）。
[15] 對每個標準C 頭文件，它將名字放入全局名字空間；與之對應的頭文件將名字放入名字空間std。
[16] 許多系統有一個"String.h"頭文件裏定義了一個串類型。注意，這個串類型與標準庫的string 不同。
[17] 儘可能使用標準庫功能，而不是非標準的功能。
[18] 在聲明C 函數時用extern "C"。
附錄C
[1] 應集中關注軟件開發而不是技術細節。
[2] 堅持標準並不能保證可移植性。
[3] 避免無定義行爲（包括專有的擴充）。
[4] 將那些實現定義的行爲局部化。
[5] 在沒有{、}、[、]、|或!的系統裏用關鍵字和二聯符表示程序，在沒有\的地方用三聯符。
[6] 爲了方便通信，用ASCII 字符去表示程序。
[7] 採用符號轉義字符比用數值表示字符更好些。
[8] 不要依賴於char 的有符號或者無符號性質。
[9] 如果對整數文字量的類型感到有疑問，請使用後綴。
[10] 避免破壞值的隱式轉換。
[11] 用vector 比數組好。
[12] 避免union。
[13] 用位域表示外部確定的佈局。
[14] 注意不同存儲管理風格間的權衡。
[15] 不要污染全局名字空間。
[16] 在需要作用域（模塊）而不是類型的地方，用namespace 比class 更合適。
[17] 記住static 類成員需要定義。
[18] 用typename 消除對模板參數中類型成員的歧義性。
[19] 在需要用模板參數顯式限定之處，用template 消除模板類成員的歧義性。
[20] 寫模板定義時，應儘可能減少對實例化環境的依賴性。
[21] 如果模板實例化花的時間過長，請考慮顯式實例化。
[22] 如果需要編譯順序的顯式可預見性，請考慮顯式實例化。
附錄D
[1] 應預期每個直接與人打交道的非平凡程序或者系統都會用在多個國家。
[2] 不要假定每個人使用的都是你所用的字符集。
[3] 最好是用locale 而不是寫實質性代碼去做對文化敏感的I/O。
[4] 避免將現場名字字符串嵌入到程序正文裏。
[5] 儘可能減少全局格式信息的使用。
[6] 最好是用與現場有關的字符串比較和排序。
[7] 保存facet 的不變性。
[8] 應保證改變現場的情況只出現在程序裏的幾個地方。
[9] 利用現場去管理刻面的生存期。
[10] 在寫對現場敏感的I/O 函數時，記住去處理用戶（通過覆蓋）提供的函數所拋出的異常。
[11] 用簡單的Money 類型保存貨幣值。
[12] 要做對現場敏感的I / O，最好是用簡單的用戶定義類型保存所需的值（而不是從內部類型的值強制轉換）。
[13] 在你對涉及到的所有因素有了很好的看法之前，不要相信計時結果。
[14] 當心time_t 的取值範圍。
[15] 使用能接受多種輸入格式的日期輸入例程。
[16] 最好採用那些明顯表明了所用現場的字符分類函數。
附錄E
[1] 弄清楚你想要什麼級別的異常時安全性。
[2] 異常時安全性應該是整體容錯策略的一部分。
[3] 爲所有的類提供基本保證，也就是說，維持一個不變式，而且不流失資源。
[4] 在可能和可以負擔之處提供強保證，使操作或者成功，或者保持所有操作對象不變。
[5] 不要從析構函數裏拋出異常。
[6] 不要從一個遍歷合法序列的迭代器裏拋出異常。
[7] 異常時安全性涉及到仔細檢查各個操作。
[8] 將模板設計爲對異常透明的。
[9] 更應該用申請資源的構造函數方式，不要採用init()函數。
[10] 爲類定義一個不變式，使什麼是合法狀態變得非常清晰。
[11] 確保總將對象放在合法狀態中，也不要怕拋出異常。
[12] 保持不變式簡單。
[13] 在拋出異常之前，讓所有操作對象都處於合法狀態。
[14] 避免資源流失。
[15] 直接表示資源。
[16] 記住swap()有時可以成爲複製元素的替代方式。
[17] 在可能時依靠操作的順序，而不是顯式地使用try 塊。
[18] 在替代物已經安全生成之前不銷燬"老"信息。
[19] 依靠"資源申請即初始化"技術。
[20] 確保關聯容器的比較操作能夠複製。
[21] 標明關鍵性數據結構，併爲它們定義能夠提供強保證的操作。