目錄

• 類/物件
  • 1.多型基類的解構函式應總是public virtual,否則應為protected
  • 2.編譯器會隱式生成預設構造,複製構造,複製賦值,析構,(C++11)移動構造,(C++11)移動賦值的inline函式
  • 3.不要在解構函式丟擲異常，也儘量避免在建構函式丟擲異常
• 模板
  • 1. 不要偏特化模板函式，而是選擇過載函式。
  • 2.(C++11)不要過載轉發引用的函式，否則使用其它替代方案
• 函式
  • 1.(C++11)禁用某個函式時，使用 = delete而非private
  • 2.(C++11)lambda表示式一般是函式物件。特殊地，在無捕獲時是函式指標。
  • 3.(C++11)儘可能使用lamada表示式代替std::bind
  • 4.(C++11)使用lambda表示式時，避免預設捕獲模式
• 記憶體相關
  • 1.檢查new是否失敗通常是無意義的。
  • 2.儘量避免多次new同一種輕量級型別，而是先new一個大區域再分配多次。
• STL標準庫
  • 1.(C++11)使用emplace/emplace_back/emplace_front而不是insert/push_back/push_front
  • 2.在遍歷容器時刪除迭代器需謹慎
  • 3.容器的at()會檢查邊界，[]則不檢查邊界
  • 4.sort()的< 比較操作符，若兩者相等則必須返還失敗。
  • 5.永遠記住，更低的時間複雜度並不意味著更高的效率
• 優化與效率
  • 1.儘可能使用 ++i 而不是 i++
  • 2.在後期遇到效能瓶頸，萬不得已時才使用inline
  • 3.儘量不使用dynamic_cast並且禁用RTTI
• 異常
  • 1.(C++11)若保證異常不會丟擲，應使用noexpect異常規格，否則不要宣告異常規格。
• 雜項
  • 1.(C++17)需要用到任意可變的型別時，使用std::any，std::variant而不是union
  • 2.(C++11)auto只能推匯出型別型別，而decltype能夠推匯出宣告型別
  • 3.(C++11)使用nullptr而不是NULL或0
  • 4.(C++11)使用enum class語法為列舉型別提供限定範圍
  • 5.(C++11)只要潛在編譯期可計算的函式/變數，就使用constexpr
• 參考

前言：C++是博大精深的語言，特性複雜得跟北京二環一樣，繼承亂得跟亂倫似的。

不過它仍然是我最熟悉且必須用在遊戲開發上的語言，這篇文章用於挑選出一些個人覺得重要的條款/經驗/技巧進行記錄總結。
文章最後列出一些我看過的C++書籍/部落格等，方便參考。

其實以前也寫過相同的筆記博文，現在用markdown”重置“一下。

類/物件

1.多型基類的解構函式應總是public virtual,否則應為protected

當要釋放多型基類指標指向的物件時，為了按正確順序析構，必須得藉助virtual從而先執行析構派生類再析構基類。
當基類沒有多型性質時，可將基類解構函式宣告protected，並且也無需耗費使用virtual。

2.編譯器會隱式生成預設構造,複製構造,複製賦值,析構,(C++11)移動構造,(C++11)移動賦值的inline函式

當你在程式碼中用到以上函式時且沒有宣告該函式時，就會預設生成相應的函式。
特殊的，當你聲明瞭建構函式（無論有無引數），都不會隱式生成預設建構函式。
不過隱式生成的函式比自己手寫的函式（即使行為一樣）效率要高，因為經過了編譯器特殊優化。

(c++11)當你需要顯式禁用生成以上某個函式時,可在宣告函式 = delete
例如：

Type(const Type& t) = delete;

(c++11)當你需要顯式預設生成以上某個函式時，可在宣告函式 = default
例如：

Type(Tpye && t) = default;

3.不要在解構函式丟擲異常，也儘量避免在建構函式丟擲異常

解構函式若丟擲異常，可能會使解構函式過早結束，從而可能導致一些資源未能正確釋放。
建構函式若丟擲異常，則無法呼叫解構函式，這可能導致異常發生前部分資源成功分配，卻沒能執行解構函式的正確釋放行為。

模板

1. 不要偏特化模板函式，而是選擇過載函式。

編譯器匹配函式時優先選擇非模板函式（過載函式），再選擇模板函式，最後再選擇偏特化模板函式。
當匹配到某個模板函式時，就不會再匹配選擇其他模板函式，即使另一個模板函式旗下有更適合的偏特化函式。
所以這很可能導致編譯器沒有選擇你想要的偏特化模板函式。

2.(C++11)不要過載轉發引用的函式，否則使用其它替代方案

轉發引用的函式是C++中最貪婪的函式，容易讓需要隱式轉換的實參匹配到不希望的轉發引用函式。（例如下面）

template<class T>
  void f(T&& value);

void f(int a);

//當使用f(long型別的引數)或者f(short型別的引數)，則不會匹配int版本而是匹配到轉發引用的版本

替代方案：

1. 捨棄過載。換個函式名或者改成傳遞const T&形參。
2. 使用更復雜的標籤分派或模板限制（不推薦）。

函式

1.(C++11)禁用某個函式時，使用 = delete而非private

原因有4個：

• private函式仍需要寫定義（即使那是空的實現），
• 派生類潛在覆蓋禁用函式名的可能性，
• “=delete”語法比private語法更直觀體現函式被禁用的特點，
• 在編寫非類函式的時候，無法提供private屬性。

一般 = delete的類函式應為public，因為編譯器先檢測可訪問性再檢驗禁用性

2.(C++11)lambda表示式一般是函式物件。特殊地，在無捕獲時是函式指標。

編譯器編譯lambda表示式時實際上都會對每個表示式生成一種函式物件型別，然後構造出函式物件出來。
特殊地，lambda表示式在無任何捕獲時，會被編譯成函式，其表示式值為該函式指標（畢竟函式比函式物件更效率）。
因此在一些老舊的C++API只接受函式指標而不接受std::function的時候，可以使用無捕獲的lamdba表示式。

3.(C++11)儘可能使用lamada表示式代替std::bind

直接舉例說明，假設有如下Func函式：

void Func(int a, float b)；

現在我們讓Func繫結上2.0f作為引數b，轉化一個void(int a)的函式物件。

std::function<void(int)> f;
float b = 2.0f;

//std::bind寫法
f = std::bind(Func, std::placeholders::_1, b);
f(100);

//lambda表示式寫法
f = [b](int a) {Func(a, b); };
f(100);

可以看到使用std::bind會十分不美觀不直觀，還得注意佔位符位置順序。
而使用lambda表示式可以讓程式碼變得十分簡潔優雅。

4.(C++11)使用lambda表示式時，避免預設捕獲模式

按引用預設捕獲容易造成引用空懸，而顯示的引用捕獲更能容易提醒我們捕獲的是哪個變數的引用，從而更容易理清該引用的生命週期。
按值預設捕獲容易讓人誤解lambda式是自洽的（即不依賴外部）。下面是一個典型例子：

void test() {
   static int a = 0;
   auto func = [=]() {
   return a + 2;
   };
   a++;
   int result = func();
}

由於預設捕獲，你以為a是以按值拷貝過去，所以期待result總會會是2。但是實際上你是呼叫了同一個作用域的靜態變數，沒有拷貝的行為。

所以，無論是按值還是引用，都儘量指定變數，而不是用預設捕獲。

記憶體相關

1.檢查new是否失敗通常是無意義的。

new幾乎總是成功的，現代大部分作業系統採取程序的惰式記憶體分配（即請求記憶體時不會立即分配記憶體，當使用時才慢慢吞吞分配）。
所以當使用new時，通常不會立即分配記憶體，從而無法真正檢測到是否記憶體將會耗盡。

2.儘量避免多次new同一種輕量級型別，而是先new一個大區域再分配多次。

每次new的時候，實際上還會額外分配出一個存放記憶體資訊的區域，而多次分配記憶體給輕量級型別時，會造成臃腫的記憶體資訊。
而且在刪除這些區域時，很容易造成很多塊記憶體碎片，導致記憶體利用率不高。
所以應當使用記憶體池的方式，先new一大塊區域，再從區域分配記憶體給輕量級型別。

STL標準庫

1.(C++11)使用emplace/emplace_back/emplace_front而不是insert/push_back/push_front

emplace 最大的作用是避免產生不必要的臨時變數，因為它可以直接在容器相應的位置根據引數來構造變數。
而 insert / push_back / push_front 操作是會先通過引數構造一個臨時變數，然後將臨時變數移動到容器相應的位置。

2.在遍歷容器時刪除迭代器需謹慎

順序式容器刪除迭代器會破壞本身和後面的迭代器，節點式容器刪除迭代器會破壞本身，導致迴圈遍歷崩潰（迴圈遍歷依賴於容器原有的迭代器）。

兩個值得借鑑的正確做法：

auto it = vec.begin();
while (it != vec.end()){
    if (...){
        // 順序式容器的erase()會返回緊隨被刪除元素的下一個元素的有效迭代器
        it = vec.erase(it);
    }
    else{
        it++;
    }
}

auto it = list.begin();
while (it != list.end()){
    if (...) {
        t.erase(it++);
    }
    else {
        it++;
    }
}

3.容器的at()會檢查邊界，[]則不檢查邊界

STL小細節。另外std::vector

4.sort()的< 比較操作符，若兩者相等則必須返還失敗。

STL的sort演算法基本是快排，是不穩定的排序。
若比較的兩者相等時返還成功，則不穩定排序容易出現死迴圈，從而導致程式崩潰。

5.永遠記住，更低的時間複雜度並不意味著更高的效率

STL容器，特別是set,map，有著很多O(logN)的操作速度，但並不意味著是最佳選擇，因為這種複雜度表示往往隱藏了常數很大的事實。

例如說，集合的主流實現是基於紅黑樹，基於節點儲存的，而每次插入/刪除節點都意味著呼叫一次系統分配記憶體/釋放記憶體函式。這相比vector等向量容器所有操作僅一次系統分配記憶體（理想情況來說），實際上就慢了不少。

此外，向量容器對CPU快取更加友好，遍歷該種容器容易命中快取，而節點式容器則相對容易命中失敗。

綜合上述，如果要選擇一個最適合的容器，那麼不要過度信賴時間複雜度，除非你十分徹底的瞭解STL容器，或對各容器進行多次效率測試。

優化與效率

1.儘可能使用 ++i 而不是 i++

這個是老生常談的C++經典問題，對於int/unsigned等內建型別時，++i與i++似乎在效率上沒有區別。
然而在使用迭代器或其他自定義型別時，i++往往還得建立一個額外的副本來用於返還值，而++i則直接返還它本身。

2.在後期遇到效能瓶頸，萬不得已時才使用inline

現代編譯器已經十分智慧，很多時候該寫成inline的函式編譯器會自動幫你inline，不該inline的時候即使你顯式寫了inline編譯器也有可能認為不該inline。
也就是說顯式的寫出inline只是給編譯器一個建議，它不一定會採納。
因此在開發時不用過早優化，過早考慮inline，而是遇到效能瓶頸時才考慮使用顯式寫出inline，不過大部分這時候你更應該考慮的是你寫的演算法效率。

3.儘量不使用dynamic_cast並且禁用RTTI

依靠dynamic_cast的程式碼往往可以用多型虛擬函式解決，而且多型虛擬函式更加優雅。因此，儘可能避免編寫dynamic_cast。
另外可以隨之禁用與dynamic_cast相關的RTTI特性，禁用該特性可以提升程式效率（每個類少一些臃腫的RTTI資訊）。

異常

1.(C++11)若保證異常不會丟擲，應使用noexpect異常規格，否則不要宣告異常規格。

無宣告異常規格，意思是可能丟擲任何異常。
相比無宣告異常規格的函式，noexpect函式能得到編譯器的優化（發生異常時不必解開棧），且能清晰表示自己的無異常保證。

雜項

1.(C++17)需要用到任意可變的型別時，使用std::any，std::variant而不是union

union是從c繼承來的特性，它的成員不可以是帶建構函式，解構函式，自定義複製建構函式的c++類。
因此最好不要使用union，而是用std::any或std::variant ，目前C++17已引入<any>庫和<variant>庫。

2.(C++11)auto只能推匯出型別型別，而decltype能夠推匯出宣告型別

int& value = 233;
auto a = value;//auto是int型別
decltype(auto) b = value; //decltype(auto)是int&型別

也就是說auto的推導型別會拋棄引用性質，而decltype能夠推匯出完整的宣告型別。

3.(C++11)使用nullptr而不是NULL或0

NULL是C語言遺留的東西，是將巨集定義成0的，容易造成指標和整數的二義性。
而nullptr很好的避免了整數的性質。

4.(C++11)使用enum class語法為列舉型別提供限定範圍

C帶來的enum語法是允許列舉類進行隱式轉換的，潛在造成程式設計師不希望發生的轉換。
而C++11的enum class會阻止隱式轉換，需要程式設計師顯示轉換

enum class Color{Red,Blue,Green};
Color color = Color::Red;
int i = static<int>(color);

5.(C++11)只要潛在編譯期可計算的函式/變數，就使用constexpr

constexpr能讓一些函式/變數在編譯期就可計算，可減少執行期運算。（可視作模板元運算的美化語法）
此外，constexpr如果接受的是執行期變數/引數，則會變成執行期計算。
也就是說它既可用作編譯期運算，也可執行期運算，語境作用域比非constexpr更廣。

參考

• 《C++ Primer Plus》：當初入門C++語言的書籍。
• 《C++程式設計語言（特別版）》：C++之父編寫的入門教材，但實際上更應該算為介於入門與進階之間的工具書（用於查詢語法）。
• 《Effective C++》：C++ 進階書，深入理解與經驗
• 《More Effective C++》：C++ 進階書，深入理解與經驗
• 《深度探索C++物件模型》：C++ 進階書，深入理解
• 《Expectional C++》：C++ 進階書，深入理解與經驗
• 《高速上手 C++11/14/17》：C++11/14/17 入門書，介紹C++11/14/17各項新特性的基礎用法，它目前只有電子版本： https://github.com/changkun/modern-cpp-tutorial/blob/master/book/zh-cn/toc.md
• 《Effective Modern C++》：C++11/14 進階書，介紹C++11/14部分新特性的深入理解與經驗。
• 《遊戲程式設計精粹 2》：遊戲程式設計綜合技術書，有部分章節講C++的經驗。
• 《遊戲程式設計精粹 3》：同上。

C++是非常非常複雜的語言，看的這方面書越多就越覺得自己的無知（例如C++ Boost）。
但是在學習C++的中途也必須認識到，C++是一門工具，不要過多鑽C++語言的牛角尖。
謹記：程式設計師是要成為工程師而不是語言學