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

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

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

使用移動(dòng)語義

避免創(chuàng)建臨時(shí)對(duì)象

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

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

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

迭代 vs 遞歸

選擇高效的算法

利用緩存

profiling

other碎碎念

以下為正文：

值傳遞還是引用傳遞：

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

在某些情況下，值傳遞并移動(dòng)實(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_;};

因?yàn)闊o論如何都會(huì)對(duì)它們進(jìn)行拷貝。

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

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

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

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

但是，按值返回對(duì)象通常沒啥大問題。因?yàn)橐话闱闆r下他們會(huì)觸發(fā)返回值優(yōu)化或移動(dòng)語義，即不會(huì)有多余的拷貝動(dòng)作。

使用移動(dòng)語義：

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

避免創(chuàng)建臨時(shí)對(duì)象：

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

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

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

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

返回值優(yōu)化

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

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

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

cout 《《 createPerson（）;

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

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

createPerson（）;

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

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

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

預(yù)分配內(nèi)存：

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

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

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

迭代 vs 遞歸：

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

選擇效率更高的算法：

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

盡可能多的使用緩存：

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

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

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

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

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

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

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

profiling：

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

對(duì)此我整理了一份腦圖：

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

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

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

如果代碼的圈復(fù)雜度或認(rèn)知復(fù)雜度過大，可能函數(shù)本身實(shí)現(xiàn)的過于復(fù)雜，或可能因?yàn)榧軜?gòu)設(shè)計(jì)過于復(fù)雜，導(dǎo)致函數(shù)過于復(fù)雜。

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

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

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

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

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

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

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

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

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

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

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

幫助代碼設(shè)計(jì)人員更專注于分析和解決代碼設(shè)計(jì)缺陷

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

舉例如下：

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

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

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

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

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

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

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

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

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

代碼覆蓋率的意義：

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

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

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

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

動(dòng)態(tài)分析工具可以在程序運(yùn)行時(shí)發(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：未定義行為

● 編譯選項(xiàng)添加fsanitize=address/memory/thread/undefined

還有Valgrind工具：

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

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

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

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

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

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

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

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

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

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

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

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

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

other碎碎念：

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

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

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

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

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

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

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

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

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

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

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

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

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

最后想說一句：

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

責(zé)任編輯：haq