Exceptional C++

（翻譯的太差了）

一、文法細節

C++不允許修改內建類型的臨時變數 預設參數根據靜態類型獲得 重載的new和delete操作符永遠都是靜態，不管你聲明static沒有

二、慣用法

選擇前置遞增，只有打算使用初始值時才使用後置遞增，並且使用前置遞增來實現後置遞增 注意由隱式轉換建立的隱藏臨時對象；避免這個問題的好辦法，是使用explicit建構函式，避免編寫轉換操作符 永遠不要#include不必要的標頭檔；當前置聲明足夠時，永遠不要#include標頭檔 明智的使用名稱空間：如果將一個類放入一個名字空間內，那麼一定也要將所有的輔助函數和操作符放入相同的名字空間中 永遠不要多態的處理數組；語言要求傳遞給delete[]操作符的指標類型必須與它的動態類型保持一致 const auto_ptr<>，對特定問題幾乎完美的慣用法

三、原則

GLSP：泛型的Liskov替換原則：當作模板參數傳遞的任何類型（或模板）都應當遵守這個參數的需求 需要特別注意賦值操作符的異常安全性，因為它與拷貝建構函式是不一樣的 優先選擇內聚性，設法使每塊代碼（每個模組，每個類，每個函數）具有單一的，定義良好的職責；如果一塊代碼由於內在的設計問題而不能被編寫成異常安全的，那幾乎總是拙劣設計的表現，例如，帶有兩個不同職責的函數是難於編寫成異常安全的 遵守規範的異常安全性規則：（1），永遠不要允許異常逃離解構函式、重載的delete()和delete[]()操作符；（2），設法使用RAII來隔離資源資源所有權和資源管理；（3），在每個函數中，將所有可能拋出異常的代碼以及能夠安全處理此類工作的代碼單獨放置到一邊，只有確信實際的工作已經完成時，才使用無異常拋出的操作來修改程式的狀態 在什麼情況下使用公有繼承？我們需要公有繼承來表示is-a關係，所有被改寫的成員函數必須不要求更多，也不要承諾更少；永遠不要為了重用基類中的代碼而進行公有繼承； 在什麼情況下使用非公有繼承而不是包含？（1），我們需要改寫一個虛函數；（2），我們需要訪問保護成員；（3），我們需要在另一個基類子物件之前構造被使用類，或者在其之後析構被使用類；（4），我們需要共用共用的虛擬基類，或者改寫虛擬基類的構造；（5），我們從空基類最佳化上獲益匪淺；（6），我們需要“受控的多態”，但只是在某種代碼中 介面規則：對於一個類X，所有“提及”X和與X“一起提供”的函數（包括自由函數）邏輯上都是X的一部分，因為它們構成了X介面的一部分；成員函數與非成員函數邏輯上都可能是類的一部分，然而，成員函數仍然比非成員函數與類有更強的關係；“一起提供”的一種有用的詮釋方式是“出現在相同的標頭檔和/或名稱空間中”，如果出現在相同標頭檔中，那麼它們在依存關係上是類的一部分，如果出現在相同名稱空間中，那麼它們在名字尋找的意義上是類的一部分

四、實踐

使用自己最熟悉的技術構造產品的核心部分，在擴充部分實驗自己感興趣的新技術並從中學習 記住電腦科學格言：大多數問題都可以通過增加一個間接層來解決，當然，用奧坎姆剃刀（Occam's Razor）來調和一下是明智的：不要使事情變得比必要的更複雜

五、觀點

C++標準化工作對C++最重要的貢獻是：對“強大的抽象概念”更有力的支援，以降低軟體的複雜性； 物件導向編程的最重要的優點：是通過管理代碼之間的依存關係來降低軟體的複雜性

六、問題

標準庫是不是沒有提供定長數組的封裝類？vector是不是足夠用了？ 沒有auto_array_ptr<>，或者auto_ptr對數組的特化，是不是應該始終用vector來代替動態分配記憶體的數組？