讓C++代碼更加高效的幾個小技巧

今天和大家介紹一下能讓C++代碼更加高效的幾個小技巧，話不多說，以下為本文目錄：

參數(shù)傳遞方式：值傳遞還是引用傳遞

函數(shù)返回方式：按值返回還是按引用返回

使用移動語義

避免創(chuàng)建臨時對象

了解返回值優(yōu)化

考慮預分配內(nèi)存

考慮內(nèi)聯(lián)

迭代 vs 遞歸

選擇高效的算法

利用緩存

profiling

other碎碎念

以下為正文：

值傳遞還是引用傳遞：

一般情況下使用const的引用參數(shù)。對于函數(shù)本身會拷貝的參數(shù)，最好使用值傳遞，但只有當參數(shù)的類型支持移動語義時才這樣。

在某些情況下，值傳遞并移動實際上是向函數(shù)傳遞參數(shù)的最佳方式（注意看后面的tips），例如：

class A { public： A（const std：：string &str） { str_ = str; }

private： std：：string str_;};

可以考慮改為這種形式：

class A { public： A（std：：string str） { str_ = std：：move（str）; }

private： std：：string str_;};

因為無論如何都會對它們進行拷貝。

tips：看有些資料說后者值傳遞是更好的參數(shù)傳遞方式，貌似有些道理，但是我沒找到非常合理的理由，有知道的讀者可以在評論區(qū)留言。

按值返回還是按引用返回：

可以通過從函數(shù)中按引用方式返回對象，以避免對象發(fā)生不必要的復制。但有時不可能通過引用返回對象，例如編寫重載的operator+和其他類似運算符時。

永遠都不要返回指向局部對象的引用或指針，局部對象會在函數(shù)退出時被銷毀。

但是，按值返回對象通常沒啥大問題。因為一般情況下他們會觸發(fā)返回值優(yōu)化或移動語義，即不會有多余的拷貝動作。

使用移動語義：

盡量確保對象擁有移動構(gòu)造函數(shù)和移動賦值運算符。對象有了移動語義后，許多操作都會更加高效，特別是與標準庫和算法相結(jié)合時。

避免創(chuàng)建臨時對象：

沒有必要的臨時對象能避免就避免。一般來說，應該避免迫使編譯器構(gòu)造臨時對象的情況。盡管有時這是不可避免的，但是至少應該意識到這項“特性”的存在，這樣才不會為實際性能和分析結(jié)果而感到驚訝。編譯器還會使用移動語義使臨時對象的效率更高。這是要在類中添加移動語義的另一個原因。

《More Effective C++》第19條款中介紹過：所謂的臨時對象并不是程序員創(chuàng)建的用于存儲臨時值的對象，而是指編譯器層面上的臨時對象：這種臨時對象不是由程序員創(chuàng)建，而是由編譯器為了實現(xiàn)某些功能（例如函數(shù)返回，類型轉(zhuǎn)換等）而創(chuàng)建。

比如下面的代碼就會有臨時對象的產(chǎn)生：

void Func（const std：：string& s）;char arr［］=“hello”;Func（aar）; // here

返回值優(yōu)化

通過值返回對象的函數(shù)可能導致創(chuàng)建一個臨時對象?？聪旅娴拇a：

Person createPerson（）{ Person newP { “Marc”， “Gregoire”， 42 }; return newP;}

假如像這樣調(diào)用這個函數(shù)（假設Person 類已經(jīng)實現(xiàn)了operator《《運算符）：

cout 《《 createPerson（）;

即便這個調(diào)用沒有將createPerson（）的結(jié)果保存在任何地方，也必須將結(jié)果保存在某個地方，才能傳遞給operator《《。為此編譯器創(chuàng)建一個臨時變量，來保存createPerson（）返回的Person 對象。

即使這個函數(shù)的結(jié)果沒有在任何地方使用，編譯器也仍然可能會生成創(chuàng)建臨時對象的代碼：

createPerson（）;

編譯器可能生成代碼來創(chuàng)建一個臨時對象來保存返回值，即使這個返回值沒有使用也是如此。

不過吧，編譯器會在大多數(shù)情況下優(yōu)化掉臨時變量，以避免復制和移動。

關于返回值優(yōu)化我之前有篇文章介紹過，感興趣的可以看看這個：《左值引用、右值引用、移動語義、完美轉(zhuǎn)發(fā)，你知道的不知道的都在這里》

預分配內(nèi)存：

比如標準化容器中的reserve，需要頻繁創(chuàng)建內(nèi)存的地方可以考慮預分配一塊內(nèi)存出來，避免頻繁的創(chuàng)建內(nèi)存。

內(nèi)聯(lián)函數(shù)：

短函數(shù)可以使用內(nèi)聯(lián)消除函數(shù)開銷。

迭代 vs 遞歸：

這里我更傾向于選擇迭代方式，而不是遞歸。遞歸占用大量棧內(nèi)存，且可能會產(chǎn)生很多不必要的臨時對象構(gòu)建。

選擇效率更高的算法：

學計算機的估計沒有不知道算法的吧，學算法估計沒有人不知道如何計算時間復雜度和空間復雜度吧，在平時開發(fā)過程中遇到算法問題時我們可盡量選擇效率更高的算法，比如O（N）和O（N2）的算法，我們肯定要選擇O（N）的呀，這里可以了解下C++的，這里引入了很多高效的算法供我們使用。

盡可能多的使用緩存：

將某些數(shù)據(jù)保存下來供下次使用，避免再次獲取或重新計算它們。如果任務或計算特別慢，應該保證不執(zhí)行那些沒有必要的任務或者重復計算。

網(wǎng)絡通信：如果頻繁發(fā)起相同的網(wǎng)絡請求，可考慮將第一次的網(wǎng)絡請求結(jié)果保存在內(nèi)存中，或文件中？

磁盤訪問：如果頻繁訪問一個文件，可考慮將這個文件的內(nèi)容保存在內(nèi)存中。

數(shù)學計算：某些很耗時很復雜的運算，可考慮只執(zhí)行這種計算一次，然后共享結(jié)果。

對象分配：如果需要大量頻繁創(chuàng)建和銷毀短期對象，可考慮使用對象池。

線程創(chuàng)建：如果需要大量頻繁創(chuàng)建和銷毀線程，可考慮使用線程池。

做客戶端開發(fā)的朋友應該都聽說多級緩存的概念，就是這個原理。

profiling：

那到底什么樣的代碼才算是高質(zhì)量代碼呢？

對此我整理了一份腦圖：

如何能夠提升代碼質(zhì)量呢，除了我們自身過硬的編碼能力，還需要制定代碼檢查流程，一般代碼檢查有以下幾種方式：

代碼檢查要檢查的問題有：

腦圖中有一些代碼度量指標，它用于量化代碼質(zhì)量：

如果代碼的圈復雜度或認知復雜度過大，可能函數(shù)本身實現(xiàn)的過于復雜，或可能因為架構(gòu)設計過于復雜，導致函數(shù)過于復雜。

如果函數(shù)嵌套過深，說明函數(shù)很可能出錯，需要仔細進???評審，并且函數(shù)可能需要重構(gòu)。

如果模塊的扇入過大，說明模塊可能是公共模塊，需要??評審接?是否是穩(wěn)定的，或模塊承擔過多職責，可以考慮遵循單?職責，分解模塊的職責。

如果模塊的扇出過大，說明該模塊依賴多個模塊，可以考慮把被依賴的多個模塊合并為?個模塊，重構(gòu)依賴的接?。

如果類的繼承樹過深，考慮在繼承樹的深度上是否有新的變化?向，考慮提出新的策略類，或其他設計模式來優(yōu)化繼承樹。

如果子類過多，檢查?類的實現(xiàn)中共同的地?，先考慮提出公共的中間?類，檢查是否可以通過橋接模式、裝飾模式、組合模式等結(jié)構(gòu)型模式重構(gòu)代碼。

上面腦圖所說的需要檢查的各種問題中，代碼和需求背離問題與代碼是否符合設計問題需要人工評審，成本較高，其它問題可以通過工具來檢測。

檢測工具主要分為靜態(tài)代碼分析工具和動態(tài)代碼檢測工具。

靜態(tài)代碼分析工具主要用于靜態(tài)代碼分析，關于靜態(tài)代碼分析，它能夠根據(jù)規(guī)則幫助檢查代碼缺陷，然而，對于檢查規(guī)則能夠覆蓋的代碼，工具能夠工作的挺好，但對于規(guī)則沒有覆蓋的代碼，它卻無能為力，而且可能存在誤報問題。

靜態(tài)代碼分析是保證代碼質(zhì)量的重要手段，據(jù)說軟件開發(fā)中大概30%-70%的代碼邏輯設計和編碼缺陷都可以通過靜態(tài)代碼分析來發(fā)現(xiàn)和修復。它會掃描程序代碼，找出代碼中隱藏的錯誤，如參數(shù)不匹配、有歧義的嵌套語句、錯誤的遞歸、非法計算、空指針問題、越界問題、未初始化問題、內(nèi)存泄漏問題等。

靜態(tài)代碼分析工具的優(yōu)勢有：

自動執(zhí)行靜態(tài)代碼分析，快速定位代碼隱藏錯誤和缺陷

幫助代碼設計人員更專注于分析和解決代碼設計缺陷

減少在代碼人工檢查上花費的時間，提高軟件可靠性并節(jié)省開發(fā)成本

舉例如下：

代碼規(guī)范檢查：由于拷貝粘貼造成兩個分支的代碼完全相同

void func（int in， int &out） { if （in 》 1） out++; else out++; out++;}

代碼缺陷檢查：沒有用的RAII

void func（） { std：：lock_guard《std：：mutex》（lk）; // 臨時對象，語句結(jié)束后執(zhí)行析構(gòu)，誤用的加鎖 。..}

下面是一些常見的靜態(tài)代碼分析工具：

這里推薦一個常用的代碼質(zhì)量管理平臺SonarCube，SonarQube是一個管理代碼質(zhì)量的平臺（社區(qū)版免費），用于管理代碼的質(zhì)量，它會從多個角度維護檢測代碼質(zhì)量，通過插件形式支持多種語言的代碼質(zhì)量管理和檢測。它可以安裝sonar-cxx插件，內(nèi)置了一系列C/C++代碼檢查工具，還可以應用在CI/CD流程中，和Jenkins打通，可以在提交代碼后檢查代碼是否有壞味道，不符合規(guī)范的代碼就拒絕被合入master。

還有一個很好用的靜態(tài)代碼檢測工具是Facebook的infer，它最大的優(yōu)勢是可以靜態(tài)檢測代碼內(nèi)隱藏的內(nèi)存泄漏問題，而且免費支持Android、C、OC語言。

靜態(tài)代碼分析工具可以在運行前幫助我們檢測缺陷，只有30%-70%，但不是所有缺陷，很多缺陷需要在運行時才會被發(fā)現(xiàn)。

其實我們還可以使用一些動態(tài)分析工具，通過動態(tài)分析工具可以準確定位問題，而且誤報率低，但這與測試用例強綁定，查找缺陷的比例與測試用例的覆蓋率有關，覆蓋率對于衡量代碼質(zhì)量有很大意義。

代碼覆蓋率的意義：

● 幫助我們找到未覆蓋部分的代碼，分析測試用例設計的是否充分，之后視情況決定是否可以補充測試用例。

● 檢測出代碼的壞味道，提示我們修改代碼，理清代碼邏輯關系，提升代碼質(zhì)量。

● 代碼覆蓋率高不能代表代碼質(zhì)量一定好，但代碼覆蓋率低，代碼質(zhì)量估計不會高到哪去，可以作為我們衡量代碼質(zhì)量的重要手段之一。

● 對于沒有覆蓋到的錯誤，動態(tài)分析工具也無能為力。在實際工作中，我們可以動靜結(jié)合，多種檢查手段全都用上，可以更有效的提升代碼質(zhì)量。

動態(tài)分析工具可以在程序運行時發(fā)現(xiàn)代碼的缺陷，例如內(nèi)存問題、數(shù)據(jù)競爭、未定義行為等。

常用工具有GCC&Clang的Santizer系列：

● Asan-Address Sanitizer：緩存區(qū)溢出，內(nèi)存泄漏

● Tsan-Thread Sanitizer：并發(fā)問題

● Msan-Memory Sanitizer：未初始化內(nèi)存

● Ubsan-Undefined Behavior Sanitizer：未定義行為

● 編譯選項添加fsanitize=address/memory/thread/undefined

還有Valgrind工具：

● memchek：內(nèi)存問題，包括Asan和Msan

● helgrind：線程和并發(fā)問題

● cachegrind、callgrind、massif：幫助進行性能優(yōu)化

使用各種工具與單元測試、功能測試、系統(tǒng)測試結(jié)合，提高覆蓋率，可以幫助我們發(fā)現(xiàn)更多缺陷。

前面的多數(shù)都是代碼分析工具，下面介紹一些性能分析工具，關于性能分析工具Brendan Gregg大佬的網(wǎng)站介紹的很詳細，這里貼出來一張他總結(jié)的工具圖：

這張圖從Linux內(nèi)核的各個子系統(tǒng)出發(fā)，匯總了對各個子系統(tǒng)進行性能分析時可以選擇的工具。其實還有一些好用的工具，圖里沒有提到，這里重點介紹一下：

gprof：gprof是GNU工具之一，編譯的時候，它在每個函數(shù)的出入口加入了profiling的代碼，運行時統(tǒng)計程序在用戶態(tài)的執(zhí)行信息，可以得到每個函數(shù)的調(diào)用次數(shù)，執(zhí)行時間，調(diào)用關系等信息，簡單易懂。適合于查找用戶級程序的性能瓶頸，然而對于很多耗時在內(nèi)核態(tài)執(zhí)行的程序，gprof不適合。

Oprofile：Oprofile也是一個開源的profiling工具，它使用硬件調(diào)試寄存器來統(tǒng)計信息，進行profiling的開銷比較小，而且可以對內(nèi)核進行profiling。它統(tǒng)計的信息非常多，可以得到cache的缺失率，memory的訪存信息，分支預測錯誤率等等，這些信息gprof得不到，但是對于函數(shù)調(diào)用次數(shù)，它無能為力。

簡單來說，gprof簡單，適合于查找用戶級程序的瓶頸，而Oprofile稍微有點復雜，但是得到的信息更多，更適合調(diào)試系統(tǒng)軟件。

gperftools：Google出品，值得信賴，提供整個程序的熱點分布圖，找到性能瓶頸，然后可以針對性的進行性能優(yōu)化，如圖：

那使用什么API效率更高呢，可以看下圖：

圖中的rdtsc使用較繁瑣而且不適用于所有平臺和編譯器，剩下的大家可以按需使用哈。

關于性能分析工具，程序喵整理了一份非常詳細的腦圖（精華全在腦圖里），以性能指標分類，不同指標使用什么工具進行分析，都在圖里，目錄如下：

other碎碎念：

選擇合適的數(shù)據(jù)結(jié)構(gòu)：

選擇合適的STL，想清楚什么時候用棧，什么時候用隊列，什么時候用數(shù)組，什么時候用鏈表。

某些if-else可改為switch，效率可能更高（知道為什么嗎，不知道的可以留言，人多的話考慮輸出一篇文章）。

優(yōu)先考慮棧內(nèi)存，而不是堆內(nèi)存（免得頻繁的申請釋放內(nèi)存）。

如何函數(shù)不需要返回值，就不要設置返回值。

使用位操作，移位代替乘法除法操作。

構(gòu)造函數(shù)時使用初始化方式，而不是賦值。

A：：A（） ： a_（a） {} // better

A：：A（） { a_ = a;}

明確使用模板帶來的益處：

如果使用模板并沒有給你的開發(fā)帶來任何益處，是不是可以考慮不使用它，因為調(diào)試起來真的麻煩。

函數(shù)參數(shù)的個數(shù)不要太多。

擅用emplace，有些情況下會省去一次構(gòu)造的開銷。

最后想說一句：

先完成再完美。不要一開始就想著寫最完美的代碼，很多bug都是過早過度優(yōu)化導致的。一般情況下，性能較高的代碼可讀性都不是特別高。提早優(yōu)化很可能引發(fā)很多bug。很多情況下，我們可以先完成代碼，確保功能完成且正確之后，再去考慮完善。完成代碼后，可以使用profiling工具，找到瓶頸所在，然后做相應優(yōu)化。另外產(chǎn)品和測試如果沒給你提性能需求，那優(yōu)化它干嘛！

責任編輯：haq