C++ 編程技巧筆記記錄（持續更新）

• 2019 年 10 月 3 日
• 筆記

前言：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<bool>和std::bitset的[]提供的是值拷貝，而不是引用。

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

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

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

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

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

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

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

6.需要深度優化時，使用自定義STL分配器

每個STL容器都會要求提供一個Allocator類型作為該容器的節點分配器，不提供時使用STL默認的預設分配器。

template<typename T, class Allocator = allocator<T>>  class list {...};

默認預設分配器的行為往往是簡單粗暴的new delete，這可能帶來一些效率問題和記憶體碎片問題。
而通過自己訂製分配器，我們可以把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資訊）。

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

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

異常

1.(C++11)若保證異常不會拋出，應使用noexpect異常規格，否則不要聲明異常規格。

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

雜項

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

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

2.(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);

3.(C++11)auto只能推導出類型型別，而decltype能夠推導出聲明型別

int& value = 233;  auto a = value;//auto推導出是int類型  decltype(auto) b = value; //decltype(auto)是int&類型

也就是說auto推導出的類型會拋棄引用性質，而decltype能夠推導出完整的聲明類型。

此外一提，auto是聲明類型的語法，而decltype()是一個表達式(類似於sizeof())，表達式的值是類型。

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

union是從c繼承來的特性，它的成員不可以是帶構造函數/析構函數/自定義複製構造函數的c++類。
因此在需要萬能變數的時候最好不要使用union，而是用std::any或std::variant ，目前C++17已引入<any>庫和<variant>庫。

萬能變數是指可以轉換任意類型（可擴展，如metadata）的變數，如果只固定在幾個類型之間轉換的使用union是個效率更優的選擇。

參考

• 《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/3/7：遊戲編程綜合技術書，有部分章節講C++的經驗。

C++是非常非常複雜的語言，了解得越多就越發覺得自己的無知（例如C++ Boost）。
但是在學習C++的中途也必須認識到，C++是一門工具，不要過多鑽C++語言的牛角尖。

謹記：程式設計師是要成為工程師而不是語言學家。