盡可能延後變數定義式的出現時間。只有變數在恰好要使用之前定義，程式的可讀性往往會得到提高，因為這樣不容易忘記變數說代表的意思。另一方面，這樣做可以提高程式效能，如果不需要乙個變數時卻要為它分配、釋放空間，呼叫構造、析構函式，獲取、釋放資源……這，真是太浪費了。補充一點，宣告式並不會做這些事情，所以可以考慮用宣告式替換定義式以盡量延後變數的定義。
盡量少做轉型動作。轉型意味著出錯的可能性大大提公升，轉型意味著更多的操作。如果不得不轉型，考慮使用c++ style的形式，或提供乙個專門的轉型函式。
避免返回handles指向物件內部成分。引用、指標、迭代器都是指向物件內部成分的handles，返回這些東西就把他們的生殺大權交給了別人，降低了封裝性，安全性。如果不得不使用物件內部的成分，考慮返回const型，只讓外部具有讀取的權利。
為」異常安全「而努力是值得的。「異常安全」的**不洩露任何資源，不允許資料敗壞。「異常安全」的**提供三個保證之一：(1)基本承諾。出現異常時，程式內的任何事物仍然處在有效狀態下。沒有任何物件或資料結構因此而敗壞。(2)強烈保證。操作要麼成功，要麼不成功。如果操作失敗，程式回到操作前的狀態。(3)不拋擲保證。不丟擲異常。實際情況下，函式內部呼叫的函式未必提供相應的保證，所以不能總是控制函式具有「異常安全」性，所以，如果全在你的掌控之中，請提供一種異常保證，如果不能，請在文件裡說明。
透徹了解inlining的裡裡外外。inline函式很好，但是過度的inline函式會增加程式的目標碼。因為編譯器對於inline函式的處理是：對於每個inline函式的呼叫，都以函式的本體替換之，而不是儲存現場，跳轉到函式的入口處。inline函式實現放在標頭檔案裡的原因是編譯器在編譯時就要知道inline函式是什麼樣子的，以便完成替換。另外乙個重點是inline是對編譯器的一項建議，是否真正inline由編譯器決定。如果要寫inline函式，針對那些頻繁呼叫的簡單函式。
將檔案間的編譯依存關係降至最低。如果只是修改了程式的一部分，卻要重新編譯許多不相關的模組，這真是令人焦躁而無語。這主要是由於c++的編譯規則引起的，如果a檔案裡include了b檔案，現在只是對a進行修改，那麼重新編譯時b檔案也會被重新編譯，而b檔案又include了c、d、e檔案，而c、d、e檔案又……這看起來就是個災難，所以，非常有必要將檔案間的編譯依存關係降至最低。至少有三種方式可以做出這樣的努力：
1) 能使用object reference 或 object pointer，就不要使用object。reference 或 pointer只需要乙個宣告式就可以了，不需要定義式。
2) 如果能夠，盡量以class宣告式替換class定義式。
3) 為宣告式和定義式提供不同的標頭檔案，像std那樣組織起自己的類。
pimpl idiom手法和abstract base class可以幫助實現上面的方式，並且abstract base class往往意味著多型，而這正是物件導向的思想的體現。23中經典模式裡多型還少嗎？
《Effective C 》重點摘要（一）
這個星期不再發布關於資料結構的部落格，想把半個月來看的書做一些總結，整理整理，第一本就是 effective c 第一次看這本書是一年多前，準備考研複試的時候，隨後陸陸續續，這個月再來看算是第三遍了吧，之前沒有看過 深度探索c 物件模型 所以有的地方看得不是很透徹 現在有的地方也看得不透，但是比以前...
《Effective C 》重點摘要（四）
讓介面容易被正確使用，不易被誤用。乙個介面由返回型別 介面名稱 和引數列表組成，為了讓介面容易被正確的使用，需要小心設計返回型別，最好是簡單 直接 自然。介面名稱選擇很重要，做到簡單 達意 無歧義。引數列表形參型別需要身份小心，如果能防範非法輸入，盡力為之，形參名也盡可能做到同介面名稱一樣的標準。另...
Effective C 摘要 （第1章）
effective c 第一章 c 語言元素 項1 總是使用屬性，不要使用可訪問的資料成員 項2 常數項盡量使用readonly，而不是const 項3 型別裝換時，不要使用強制轉換，使用操作符is或者as 項4 使用conditional標記代替 if條件編譯 項5 給你建立的每個類寫乙個tost...