這個google c++風格指南出得太好了，有很多c++的問題，其實通過閱讀這份文件就可以了。相信讀完後，可以在簡歷上加上一句，「具有良好的編碼風格」，哈哈。下面記錄一下我的讀書筆記吧。整份文件的中文版本我已經上傳到了資源裡面。
每次eclipse cdt新建乙個class的時候，都是做了define保護：
所有標頭檔案都應該使用 #define 防止標頭檔案被多重包含, 命名格式當是:
___h_
能用前置宣告的地方盡量不使用 #include.
當乙個標頭檔案被包含的同時也引入了新的依賴, 一旦該標頭檔案被修改, **就會被重新編譯.
如果這個標頭檔案又包含了其他標頭檔案, 這些標頭檔案的任何改變都將導致所有包含了該標頭檔案的
**被重新編譯. 因此, 我們傾向於減少包含標頭檔案, 尤其是在標頭檔案中包含標頭檔案。
使用前置宣告可以顯著減少需要包含的標頭檔案數量. 舉例說明: 如果標頭檔案中用到類 file,
但不需要訪問 file 類的宣告, 標頭檔案中只需前置宣告 class file; 而無須 #include
"file/base/file.h".
不允許訪問類的定義的前提下, 我們在乙個標頭檔案中能對類 foo 做哪些操作?
? 我們可以將資料成員型別宣告為 foo * 或 foo &.
? 我們可以將函式引數 / 返回值的型別宣告為 foo (但不能定義實現).
? 我們可以將靜態資料成員的型別宣告為 foo, 因為靜態資料成員的定義在類定義之外
. 反之, 如果你的類是 foo 的子類, 或者含有型別為 foo 的非靜態資料成員, 則必須包含 foo
所在的標頭檔案.
乙個較為合理的經驗準則是, 不要內聯超過 10 行的函式. 謹慎對待析構函式, 析構函式往往
比其表面看起來要更長, 因為有隱含的成員和基類析構函式被呼叫!
禁止使用 class 型別的靜態或全域性變數: 它們會導致很難發現的 bug 和不確定的構
造和析構函式呼叫順序. 靜態生存週期的物件, 包括全域性變數, 靜態變數, 靜態類成員變數,
以及函式靜態變數, 都必須是原生資料型別 (pod : plain old data)。
缺點:
c++ 中的隱式物件拷貝是很多效能問題和 bug 的根源. 拷貝建構函式降低了**可讀性, 相
比傳引用, 跟蹤傳值的物件更加困難, 物件修改的地方變得難以捉摸.
可以考慮在類的 private: 中新增拷貝建構函式和賦值操作的空實現, 只有宣告, 沒有定義.
由於這些空函式宣告為 private, 當其他**試圖使用它們的時候, 編譯器將報錯. 方便起見
, 我們可以使用 disallow_copy_and_assign 巨集：
#define disallow_copy_and_assign(typename) \
typename(const typename&); \
void operator=(const typename&)
class foo ;
如果類確實需要可拷貝, 應在該類的標頭檔案中說明原由, 並合理的定義拷貝建構函式和賦值操
作。優點:
rtti 在某些單元測試中非常有用. 比如進行工廠類測試時, 用來驗證乙個新建物件是否為期
望的動態型別.
除測試外, 極少用到.
缺點:
在執行時判斷型別通常意味著設計問題. 如果你需要在執行期間確定乙個物件的型別, 這通常
說明你需要考慮重新設計你的類.
優點:
不考慮返回值的話, 前置自增 (++i) 通常要比後置自增 (i++) 效率更高. 因為後置自增 (或
自減) 需要對表示式的值 i 進行一次拷貝. 如果 i 是迭代器或其他非數值型別, 拷貝的代價
是比較大的. 既然兩種自增方式實現的功能一樣, 為什麼不總是使用前置自增呢?
結論:
對簡單數值 (非物件), 兩種都無所謂. 對迭代器和模板型別, 使用前置自增 (自減).
google C 風格指南筆記（一）
看看google的c 規範和風格，學習一下。逐個來，今天先看 標頭檔案 筆記如下 1 能用前置宣告的地方盡量不使用 include.當乙個標頭檔案被包含的同時也引入了新的依賴,一旦該標頭檔案被修改,就會被重新編譯.如果這個標頭檔案又包含了其他標頭檔案,這些標頭檔案的任何改變都將導致所有包含了該標頭檔...
Google C 程式設計風格指南
每乙個c 程式設計師都知道，c 具有很多強大的語言特性，但這種強大不可避免的導致它的複雜，這種複雜會使得 更易於出現bug 難於閱讀和維護。本指南的目的是通過詳細闡述在c 編碼時要怎樣寫 不要怎樣寫來規避其複雜性。這些規則可在允許 有效使用c 語言特性的同時使其易於管理。使用前置宣告，盡量少.h檔案...
Google C 程式設計風格指南
越來越發現一致的程式設計風格的重要性，於是把google的c 程式設計風格指南看了一遍，這裡記錄下於自己有益的rules。當規則有多個選擇時，這裡只記錄個人習慣的用法，並不代表它是唯一的用法。google style guide google開源專案風格指南 命名管理是最重要的一致性規則，因此我把它...