item26：盡可能延後變數定義式的出現時間
item27：盡量少做轉型動作
關於這一點，專門開了乙個新的總結：
item28：避免返回handles指向物件的內部成分
總結：
item29：為「異常安全」而努力是值得的
當異常被丟擲時：
異常安全函式即使發生異常也不洩露資源或允許任何資料破壞。這樣的函式區分為三種可能：基本型，強烈型，不拋異常型。
「強烈保證型」往往能夠以copy-and-swap實現出來，但「強烈保證」並非對所有函式都可實現或具備現實意義。
函式提供的「異常安全保證」通常最高只等於其所呼叫的各個函式的「異常安全保證」中的最弱者。
item30：透徹了解inline的裡裡外外
inline函式通常一定被置於標頭檔案內，因為大多數環境在編譯過程中進行inling，而為了將乙個「函式呼叫」替換為「被呼叫的函式的本體」，編譯器需要知道那個函式長什麼樣子，inling在大多數c++程式中是編譯期行為。
大部分編譯器拒絕太過複雜（例如帶有迴圈或遞迴）的函式inling，而對所有的virtual函式呼叫（除非是最平淡無奇的）也都會使得inling落空。這應該不會令你驚訝，因為virtual意味著「等待，直到執行期才確定呼叫哪個函式」，而inling意味著「執行前先將呼叫的動作做替換為被呼叫函式的本體」。
inling函式無法隨著程式的公升級而公升級，換句話說，如果f是程式庫中的乙個inling函式，客戶將f函式本體編程序式中，一旦程式庫設計者決定改變f，所有用到f的客戶端程式都必須重新編譯，這將是很大的負擔，而如果f是個non-inline函式，一旦它有任何修改，客戶端都只需要重新鏈結就好，遠比重新編譯的負擔要小的多，如果程式庫採用動態連線，公升級版函式公升值可以不知不覺地被應用程序吸納。
item31：將檔案間的編譯依存關係降至最低
①如果使用object references或者object pointers可以完成任務，就不要使用objects，你可以只靠乙個型別宣告式就定義出指向該型別的references和pointers，但如果定義某型別的objects，就需要用到該型別的定義式。
②如果能夠，盡量以class宣告式替換class定義式，注意：當你宣告乙個函式而它用到某個class的時候，你並不需要該class的定義式，縱使函式以by value的方式傳遞該型別的引數（或者返回值）。
class
date;//class宣告式
date today;//沒問題，這裡並不需要date的定義式
但是在函式被呼叫之前，date的定義式一定得被**才行
Effective C 章節精簡版
1.帶有類的c c template stl 2.對於單純常量，最好以const物件替換 defines。對於形式函式的巨集，最好用inline代替巨集。enum取位址會違法.控制其域 寧願編譯器替換預處理 巨集的括號，及演算法優先順序的煩惱 3.const星號左邊 被指物體常量 const星號右邊...
《Effective C 》資源管理章節
item 13 以物件管理資源 關鍵的兩個想法 這種方式其實在很多地方都可以看出影子，比如managing pool的模型 1.獲得資源後立刻放入管理物件 managing object 以物件管理資源的觀念常常被稱為 資源取得之時就是初始化時機 resourece acquisition is i...
Effective C 讀書筆記 實現
大多數情況下，適當提出你的classes 和class templates 定義以及functions 和function templates 宣告，是花費最多心力的地方。一旦正確完成它們，相應的實現大多直截了當。儘管如此，還是有些東西需要小心。太快定義變數可能造成效率上的拖延 過度使用轉型 cas...