目錄
- 類/物件
- 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)盡可能使用lambda運算式代替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.永遠記住,更低的時間復雜度并不意味著更高的效率
- 6.需要深度優化時,使用自定義STL分配器
- 優化與效率
- 1.盡可能使用 ++i 而不是 i++
- 2.在后期遇到性能瓶頸才考慮使用inline
- 3.盡量不使用dynamic_cast并且禁用RTTI
- 4.(C++11)只要潛在編譯期可計算的函式/變數,就使用constexpr
- 例外
- 1.(C++11)若保證例外不會拋出,應使用noexpect例外規格,否則不要宣告例外規格,
- 頭檔案
- 1.做好頭檔案include gurad
- 2.注意頭檔案包含順序
- 雜項
- 1.(C++11)使用nullptr而不是NULL或0
- 2.(C++11)使用enum class語法為列舉型別提供限定范圍
- 3.(C++11)auto只能推匯出型別型別,而decltype能夠推匯出宣告型別
- 4.(C++17)需要用到任意可變的型別時,使用std::any,std::variant而不是union
- 參考
前言: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版本而是匹配到轉發參考的版本
替代方案:
- 舍棄多載,換個函式名或者改成傳遞const T&形參,
- 使用更復雜的標簽分派或模板限制(不推薦),
函式
1.(C++11)禁用某個函式時,使用 = delete而非private
原因有4個:
- private函式仍需要寫定義(即使那是空的實作),
- 派生類潛在覆寫禁用函式名的可能性,
- “=delete”語法比private語法更直觀體現函式被禁用的特點,
- 在撰寫非類函式的時候,無法提供private屬性,
一般 = delete的類函式應為public,因為編譯器先檢測可訪問性再檢驗禁用性
2.(C++11)lambda運算式一般是函式物件,特殊地,在無捕獲時是函式指標,
編譯器編譯lambda運算式時實際上都會對每個運算式生成一種函式物件型別,然后構造出函式物件出來,
特殊地,lambda運算式在無任何捕獲時,會被編譯成函式,其運算式值為該函式指標(畢竟函式比函式物件更效率),
因此在一些老舊的C++API只接受函式指標而不接受std::function的時候,可以使用無捕獲的lambda運算式,
3.(C++11)盡可能使用lambda運算式代替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容器的記憶體分配達到如下策略:
| 型別 | 策略描述 |
|---|---|
| 固定大小的緩沖池 | 所有記憶體分配都是一樣大小,減少每次分配記憶體浪費, |
| 共享記憶體 | 分配使用共享記憶體, |
| 多個堆 | 分配使用不同的堆,試分配大小和型別而定, |
| 單執行緒的 | 分配和釋放均不保證執行緒安全, |
| 垃圾回收 | 呼叫釋放的時候并不立即釋放,呼叫垃圾回收函式時才釋放, |
| 基于堆疊的策略 | 所有記憶體都是在堆疊上,適用于短生命期的容器物件, |
| 靜態記憶體 | 分配的記憶體位于程式的靜態記憶體區里, |
| 從不洗掉 | 呼叫釋放的時候不釋放記憶體,程式結束時才回收記憶體, |
| 一次性洗掉 | 呼叫釋放的時候不釋放記憶體,通過定制函式來釋放記憶體, |
| 邊界對齊策略 | 為了滿足某些條件,記憶體邊界總是對齊分配,例如在SSE中使用指令對齊記憶體的時候, |
| 除錯 | 分配記錄、檢查記憶體泄漏、檢查記憶體覆寫情況、峰值分配大小等等, |
優化與效率
1.盡可能使用 ++i 而不是 i++
這個是老生常談的C++經典問題,對于int/unsigned等內置型別時,++i與i++似乎在效率上沒有區別,
然而在使用迭代器或其他自定義型別時,i++往往還得創建一個額外的副本來用于返還值,而++i則直接返還它本身,
2.在后期遇到性能瓶頸才考慮使用inline
現代編譯器已經十分智能,很多時候該寫成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.做好頭檔案include gurad
使用宏#pragma once或者#ifndef #define ... #endif ,確保本類只會宣告一次,做好include guard,避免重復定義,
2.注意頭檔案包含順序
首先最好遵守的基本原則是:
- XXX.cpp檔案最好首先包含對應的頭檔案XXX.h,這可以避免隱含依賴,
然后下面是兩種主流的包含順序,可根據自己需要選擇(實際上隨便一種都可以,問題不大,這里就當了解一下):
-
《Google C++ Style Guide》推薦順序,先包含cpp對應頭檔案,再從最一般到最特殊的頭檔案包含順序:XXX.h、C標準庫、C++標準庫、第三方庫頭檔案、你自己工程的頭檔案,因為這更加直觀,增加可讀性,
-
《C++編程思想》推薦順序,先包含cpp對應頭檔案,再從最特殊到最一般的頭檔案包含順序:
XXX.h、你自己工程的頭檔案、第三方庫頭檔案、C++標準庫、C標準庫,這可以檢測出你的庫的頭檔案是不是包含了所有必需的頭檔案:如果某個你的庫檔案沒有包含它必需的系統檔案的話,那么這個順序就會導致編譯錯誤,
雜項
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 = https://www.cnblogs.com/KillerAery/p/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/4/5/6/7:游戲編程綜合技術書,有部分章節講C++的經驗,
- UnrealEngine 4 官方檔案 C++編碼標準:https://docs.unrealengine.com/zh-CN/Programming/Development/CodingStandard/index.html
C++是非常非常復雜的語言,了解得越多就越發覺得自己的無知(例如C++ Boost),
但是在學習C++的中途也必須認識到,C++是一門工具,不要過多鉆C++語言的牛角尖,
謹記:程式員是要成為工程師而不是語言學家,
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/102066.html
標籤:C++
上一篇:繼承(一)
下一篇:繼承(二)
