Effective C++ 50條款

---

條款 1：盡量用 const 和 inline 而不用#define——盡量用編譯器而不用預處理

1. #define max(a,b) ((a) > (b) ? (a) : (b))

條款 2：盡量用 < iostream >而不用<stdio.h>

條款 3：盡量用 new 和 delete 而不用 malloc 和 free

1. malloc 和 free(及其變體)會產生問題的原因在于它們太簡單：他們不知道構造函數和析構函數。
2. 把 new 和 delete 與 malloc 和 free 混在一起用也是個壞想法

條款 4：盡量使用 C++風格的注釋

1. C++中涉及到的內存的管理問題可以歸結為兩方面：正確地得到它和有效地使用它

條款 5：對應的 new 和 delete 要采用相同的形式

1. 用 new 的時候會發生兩件事。首先，內存被分配，然后，為被分配的內存調用一個或多個構造函數。用 delete 的時候，也有兩件事發生：首先，為將被釋放的內存調用一個或多個析構函數，然后，釋放內存。

條款 6：析構函數里對指針成員調用 delete

條款 7：預先準備好內存不夠的情況

1. 當內存分配請求不能滿足時，調用你預先指定的一個出錯處理函數。這個方法基于一個常規，即當 operator new 不能滿足請求時，會在拋出異常之前調用客戶指定的一個出錯處理函數——一般稱為 new-handler 函數

條款 8. 寫 operator new 和 operator delete 時要遵循常規

條款 9. 避免隱藏標準形式的 new

1. 在類里定義了一個稱為“ operator new”的函數后，會不經意地阻止了對標準 new 的訪問。一個辦法是在類里寫一個支持標準 new 調用方式的 operator new，它和標準 new 做同樣的事。另一種方法是為每一個增加到 operator new 的參數提供缺省值。

條款 10. 如果寫了 operator new 就要同時寫 operator delete

條款 11: 為需要動態分配內存的類聲明一個拷貝構造函數和一個賦值操作符

1. 會存在內存泄漏和重復刪除的問題
2. 只要類里有指針時，就要寫自己版本的拷貝構造函數和賦值操作符函數。

條款 12: 盡量使用初始化而不要在構造函數里賦值

1. 特別是 const 和引用數據成員只能用初始化，不能被賦值
2. 用成員初始化列表比在構造函數里賦值要好的一個原因在于效率。
3. 對象的創建分兩步：a. 數據成員初始化。b. 執行被調用構造函數體內的動作。
4. 通過成員初始化列表來進行初始化總是合法的，效率也決不低于在構造函數體內賦值，它只會更高效。另外，它簡化了對類的維護，因為如果一個數據成員以后被修改成了必須使用成員初始化列表的某種數據類型，那么，什么也不用變。
5. static 類成員永遠也不會在類的構造函數初始化。

條款 13: 初始化列表中成員列出的順序和它們在類中聲明的順序相同

1. 類成員是按照它們在類里被聲明的順序進行初始化的，和它們在成員初
   始化列表中列出的順序沒一點關系。
2. 基類數據成員總是在派生類數據成員之前被初始化

條款 14: 確定基類有虛析構函數

1. 當通過基類的指針去刪除派生類的對象，而基類又沒有虛析構函數時，結果將是不可確定的。
2. 如果某個類不包含虛函數，那一般是表示它將不作為一個基類來使用
3. 實現虛函數需要對象附帶一些額外信息，以使對象在運行時可以確定該調用哪個虛函數。對大多數編譯器來說，這個額外信息的具體形式是一個稱為 vptr（虛函數表指針）的指針。 vptr 指向的是一個稱為 vtbl（虛函數表）的函數指針數組。每個有虛函數的類都附帶有一個 vtbl。當對一個對象的某個虛函數進行請求調用時，實際被調用的函數是根據指向 vtbl 的 vptr 在 vtbl 里找到相應的函數指針來確定的。
4. 無故的聲明虛析構函數和永遠不去聲明一樣是錯誤的。
5. 虛析構函數工作的方式是：最底層的派生類的析構函數最先被調用，然后各個基類的析構函數被調用。
6. 無故的聲明虛析構函數和永遠不去聲明一樣是錯誤的

條款 15: 讓 operator=返回*this 的引用

1. 總要遵循 operator=輸入和返回的都是類對象的引用的原則

條款 16: 在 operator=中對所有數據成員賦值

條款 17: 在 operator=中檢查給自己賦值的情況

1. 在賦值運算符中要特別注意可能出現別名的情況，其理由基于兩點。其中之一是效率。
2. 另一個更重要的原因是保證正確性。

條款 18: 爭取使類的接口完整并且最小

條款 19: 分清成員函數，非成員函數和友元函數。

1. operator>>和 operator<<決不能是成員函數。

條款 20: 避免 public 接口出現數據成員

1. 結論是，在 public 接口里放上數據成員無異于自找麻煩，所以要把數據成員安全地隱藏在與功能分離的高墻后

條款 21: 盡可能使用 const

1. 使用 const 的好處在于它允許指定一種語意上的約束——某種對象不能被修改——編譯器具體來實施這種約束。
2. 在一個函數聲明中，const 可以指的是函數的返回值，或某個參數；對于成員函數，還可以指的是整個函數
3. const 成員函數的目的當然是為了指明哪個成員函數可以在 const 對象上被調用。但很多人忽視了這樣一個事實：僅在 const 方面有不同的成員函數可以重載。

條款 22: 盡量用“傳引用”而不用“傳值”

1. 提高效率
2. 避免“切割問題”

條款 23: 必須返回一個對象時不要試圖返回一個引用

條款 24: 在函數重載和設定參數缺省值間慎重選擇

1. 如果可以選擇一個合適的缺省值并且只是用到一種算法，就使用缺省參數。否則，就使用函數重載。

條款 25: 避免對指針和數字類型重載

條款 26: 當心潛在的二義性

條款 27: 如果不想使用隱式生成的函數就要顯式地禁止它

1. 顯式地聲明一個成員函數，就防止了編譯器去自動生成它的版本；使函數為 private，就防止了別人去調用它。

條款 28: 劃分全局名字空間

條款 29: 避免返回內部數據的句柄

1. 這類問題的通用解決方案和前面關于指針的討論一樣：或者使函數為非const，或者重寫函數，使之不返回句柄。

條款 30: 避免這樣的成員函數：其返回值是指向成員的非 const 指針或引用，但成員的訪問級比這個函數要低

條款 31: 千萬不要返回局部對象的引用，也不要返回函數內部用 new 初始化的指針的引用

1. 寫一個返回廢棄指針的函數無異于坐等內存泄漏的來臨。

條款 32: 盡可能地推遲變量的定義

1. 內聯函數的基本思想在于將每個函數調用以它的代碼體來替換。用不著統計專家出面就可以看出，這種做法很可能會增加整個目標代碼的體積。
2. 要牢記在心的一條是， inline 指令就象 register，它只是對編譯器的一種提示，而不是命令。
3. 一個給定的內聯函數是否真的被內聯取決于所用的編譯器的具體實現。

條款 33: 明智地使用內聯

條款 34: 將文件間的編譯依賴性降至最低

1. 句炳類：它只是把所有的函數調用都轉移到了對應的主體類中，主體類真正完成工作。
2. 協議類：協議類沒有實現；它存在的目的是為派生類確定一個接口。所以，它一般沒有數據成員，沒有構造函數；有一個虛析構函數，還有一套純虛函數，用于制定接口。
3. 句柄類和協議類都不大會使用內聯函數。使用任何內聯函數時都要訪問實現細節，而設計句柄類和協議類的初衷正是為了避免這種情況。

條款 35: 使公有繼承體現 “是一個” 的含義

1. 公有繼承聲稱：對基類對象適用的任何東西 ---- 任何！ ---- 也適用于派生類對象。

條款 36: 區分接口繼承和實現繼承

條款 37: 決不要重新定義繼承而來的非虛函數

條款 38: 決不要重新定義繼承而來的缺省參數值

1. 對象的靜態類型是指你聲明的存在于程序代碼文本中的類型
2. 對象的動態類型是由它當前所指的對象的類型決定的。
3. 虛函數是動態綁定的，意思是說，虛函數通過哪個對象被調用，具體被調用的函數就由那個對象的動態類型決定

條款 39: 避免 “向下轉換” 繼承層次

1. 從一個基類指針到一個派生類指針 ---- 被稱為 “向下轉換”

條款 40: 通過分層（組合）來體現 “有一個” 或 “用…來實現”

條款 41: 區分繼承和模板

條款 42: 明智地使用私有繼承

1. 私有繼承意味著只是繼承實現，接口會被忽略。
2. 盡可能地使用分層，必須時才使用私有繼承
3. 模板導致的 “代碼膨脹”
4. 基于私有繼承的實現避免了代碼重復
5. C++的各種特性是以非凡的方式相互作用的

條款 43: 明智地使用多繼承

1. 二義性問題——定義新類來解決
2. 基類虛擬繼承問題

條款 44: 說你想說的；理解你所說的

1. 公有繼承意味著 “是一個”
2. 私有繼承意味著 “用…來實現”
3. 分層意味著 “有一個” 或 “用…來實現”
4. 純虛函數意味著僅僅繼承函數的接口
5. 簡單虛函數意味著繼承函數的接口加上一個缺省實現
6. 非虛函數意味著繼承函數的接口加上一個強制實現

條款 45: 弄清 C++在幕后為你所寫、所調用的函數

條款 46: 寧可編譯和鏈接時出錯，也不要運行時出錯

條款 47: 確保非局部靜態對象在使用前被初始化

條款 48: 重視編譯器警告

條款 49: 熟悉標準庫

條款 50: 提高對 C++的認識

---

More Effective C++ 50條款

條款 1: 指針與引用的區別

總結

以上是生活随笔為你收集整理的Effective C++ 50条款的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。