這部分主要涉及設計的風格的事宜：基本觀點還是那句話，高內聚，低耦合，擴充套件性強，簡單
第5條 乙個實體應該只用乙個緊湊的職責
一次只解決乙個問題。乙個實體只負責一件事。
乙個實體職責過多，導致實體多重性格，難控制
典型反例：
realloc() 函式
c++ basic_string 類
第6條 正確，簡單和清晰第一
kiss（keep it ****** oftware）
典型反例：
不必要的c++ 操作符號過載
使用臨時變數作為建構函式的引數
第7條 程式設計中應知道何時和如何考慮可伸縮性
（1）使用靈活的，動態分配的資料，不要使用固定大小的陣列
（2）了解演算法的實際複雜性
（3）優先使用線性演算法或者盡可能快的演算法
（4）盡可能避免劣於線性複雜度的演算法
（5）永遠不要使用指數負載型的演算法，除非你已經山窮水盡了。
測試資料表明優化是非常必要的且重要。
第8條 不要進行不成熟的優化
第9條 不要進行不成熟的劣化
第10條 儘量減少全域性和共享資料
共享會導致衝突：避免共享資料，尤其是全域性資料。共享資料會增加耦合度，提高維護成本，降低效能
全域性名字空間中的物件名稱會無緣全域性名字空間
共享資料對單元測試不利
共享資料和全域性資料會減少多執行緒和多處理器環境的並行性
盡量降低類間的耦合性，儘量減少互動
第11條 隱藏資訊
第12條 懂得何時和如何進行併發性程式設計
儘量減少共享資料，安全地共享必須共享資料
安全法則：
（1）參考目標平台的文件，了解該平台的同步化原語（原子整數，記憶體障珊，互斥體）
（2）把平台原語用自己設計的抽象類封裝
（3）確保正在使用的型別在多執行緒中使用是安全的
外部加鎖
內部加鎖（是否為共享物件類，控制加鎖的粒度）
不加鎖（唯讀物件）
第13條 確保資源為物件所擁有。使用顯式的raii和智慧型指標
不要在一條語句中分配乙個以上的資源。raii（resource acquiresition is intialization）
每當處理需要配對的獲取、釋放函式呼叫的資源時，應該把該資源封裝在乙個物件中。
確保所有資源都為物件所有，用智慧型指標來儲存動態分配的資源，同樣應該顯式地執行資源分配。
C 程式設計規範101讀書筆記（5）類的設計與繼承
這部分主要討論物件導向的設計的一些陷阱 主要涉及建構函式，析構函式，繼承，組合，成員可見度 第32條 弄清所要編寫的是哪種類 第33條 用小類代替巨類 第34條 用組合代替繼承 在不影響呼叫 的情況下具有更大的靈活性 更好的編譯時隔離，更短的編譯時間 例外情況 1 如果需要改寫虛函式 2 如果需要訪...
C 程式設計規範101讀書筆記（1）組織和策略問題
這部分主要涉及 質量控制 第0條 不要拘泥小節 風格一致 1 縮排體現 結構 2 行長度不要影響閱讀 3 使用一致的命名規範 4 編寫有用的注釋 第1條 在高告警級別乾淨利落地編譯 1 第三方標頭檔案 pragma warning push pragma warning disable 4516 p...
C專家程式設計讀書筆記（2）
c專家程式設計讀書筆記 2 2005.12.19 1 早用lint，勤用lint，不要等到最後才用lint。lint是軟體的道德標準 2 關於typedef。先看乙個宣告 void signal int sig,void func int int 對於它，可以簡化為 typedef void ptr...