4. 函數

4.1. 參數順序

總述

函數的參數順序為: 輸入參數在先, 后跟輸出參數.

說明

C/C++ 中的函數參數或者是函數的輸入, 或者是函數的輸出, 或兼而有之. 輸入參數通常是值參或const引用, 輸出參數或輸入/輸出參數則一般為非const指針. 在排列參數順序時, 將所有的輸入參數置于輸出參數之前. 特別要注意, 在加入新參數時不要因為它們是新參數就置于參數列表最后, 而是仍然要按照前述的規則, 即將新的輸入參數也置于輸出參數之前.

這并非一個硬性規定. 輸入/輸出參數 (通常是類或結構體) 讓這個問題變得復雜. 并且, 有時候為了其他函數保持一致, 你可能不得不有所變通.

4.2. 編寫簡短函數

總述

我們傾向于編寫簡短, 凝練的函數.

說明

我們承認長函數有時是合理的, 因此并不硬性限制函數的長度. 如果函數超過 40 行, 可以思索一下能不能在不影響程序結構的前提下對其進行分割.

即使一個長函數現在工作的非常好, 一旦有人對其修改, 有可能出現新的問題, 甚至導致難以發現的 bug. 使函數盡量簡短, 以便于他人閱讀和修改代碼.

在處理代碼時, 你可能會發現復雜的長函數. 不要害怕修改現有代碼: 如果證實這些代碼使用 / 調試起來很困難, 或者你只需要使用其中的一小段代碼, 考慮將其分割為更加簡短并易于管理的若干函數.

4.3. 引用參數

總述

所有按引用傳遞的參數必須加上const.

定義

在 C 語言中, 如果函數需要修改變量的值, 參數必須為指針, 如intfoo(int*pval). 在 C++ 中, 函數還可以聲明為引用參數:intfoo(int&val).

優點

定義引用參數可以防止出現(*pval)++這樣丑陋的代碼. 引用參數對于拷貝構造函數這樣的應用也是必需的. 同時也更明確地不接受空指針.

缺點

容易引起誤解, 因為引用在語法上是值變量卻擁有指針的語義.

結論

函數參數列表中, 所有引用參數都必須是const:

void Foo(const string &in, string *out);

事實上這在 Google Code 是一個硬性約定: 輸入參數是值參或const引用, 輸出參數為指針. 輸入參數可以是const指針, 但決不能是非const的引用參數, 除非特殊要求, 比如swap().

有時候, 在輸入形參中用constT*指針比constT&更明智. 比如:

可能會傳遞空指針.

函數要把指針或對地址的引用賦值給輸入形參.

總而言之, 大多時候輸入形參往往是constT&. 若用constT*則說明輸入另有處理. 所以若要使用constT*, 則應給出相應的理由, 否則會使得讀者感到迷惑.

4.4. 函數重載

總述

若要使用函數重載, 則必須能讓讀者一看調用點就胸有成竹, 而不用花心思猜測調用的重載函數到底是哪一種. 這一規則也適用于構造函數.

定義

你可以編寫一個參數類型為conststring&的函數, 然后用另一個參數類型為constchar*的函數對其進行重載:

class MyClass { public: void Analyze(const string &text); void Analyze(const char *text, size_t textlen);};

優點

通過重載參數不同的同名函數, 可以令代碼更加直觀. 模板化代碼需要重載, 這同時也能為使用者帶來便利.

缺點

如果函數單靠不同的參數類型而重載 (acgtyrant 注：這意味著參數數量不變), 讀者就得十分熟悉 C++ 五花八門的匹配規則, 以了解匹配過程具體到底如何. 另外, 如果派生類只重載了某個函數的部分變體, 繼承語義就容易令人困惑.

結論

如果打算重載一個函數, 可以試試改在函數名里加上參數信息. 例如, 用AppendString()和AppendInt()等, 而不是一口氣重載多個Append(). 如果重載函數的目的是為了支持不同數量的同一類型參數, 則優先考慮使用std::vector以便使用者可以用列表初始化指定參數.

4.5. 缺省參數

總述

只允許在非虛函數中使用缺省參數, 且必須保證缺省參數的值始終一致. 缺省參數與函數重載遵循同樣的規則. 一般情況下建議使用函數重載, 尤其是在缺省函數帶來的可讀性提升不能彌補下文中所提到的缺點的情況下.

優點

有些函數一般情況下使用默認參數, 但有時需要又使用非默認的參數. 缺省參數為這樣的情形提供了便利, 使程序員不需要為了極少的例外情況編寫大量的函數. 和函數重載相比, 缺省參數的語法更簡潔明了, 減少了大量的樣板代碼, 也更好地區別了 “必要參數” 和 “可選參數”.

缺點

缺省參數實際上是函數重載語義的另一種實現方式, 因此所有不應當使用函數重載的理由也都適用于缺省參數.

虛函數調用的缺省參數取決于目標對象的靜態類型, 此時無法保證給定函數的所有重載聲明的都是同樣的缺省參數.

缺省參數是在每個調用點都要進行重新求值的, 這會造成生成的代碼迅速膨脹. 作為讀者, 一般來說也更希望缺省的參數在聲明時就已經被固定了, 而不是在每次調用時都可能會有不同的取值.

缺省參數會干擾函數指針, 導致函數簽名與調用點的簽名不一致. 而函數重載不會導致這樣的問題.

結論

對于虛函數, 不允許使用缺省參數, 因為在虛函數中缺省參數不一定能正常工作. 如果在每個調用點缺省參數的值都有可能不同, 在這種情況下缺省函數也不允許使用. (例如, 不要寫像voidf(intn=counter++);這樣的代碼.)

在其他情況下, 如果缺省參數對可讀性的提升遠遠超過了以上提及的缺點的話, 可以使用缺省參數. 如果仍有疑惑, 就使用函數重載.

4.6. 函數返回類型后置語法

總述

只有在常規寫法 (返回類型前置) 不便于書寫或不便于閱讀時使用返回類型后置語法.

定義

C++ 現在允許兩種不同的函數聲明方式. 以往的寫法是將返回類型置于函數名之前. 例如:

int foo(int x);

C++11 引入了這一新的形式. 現在可以在函數名前使用auto關鍵字, 在參數列表之后后置返回類型. 例如:

auto foo(int x) -> int;

后置返回類型為函數作用域. 對于像int這樣簡單的類型, 兩種寫法沒有區別. 但對于復雜的情況, 例如類域中的類型聲明或者以函數參數的形式書寫的類型, 寫法的不同會造成區別.

優點

后置返回類型是顯式地指定Lambda 表達式的返回值的唯一方式. 某些情況下, 編譯器可以自動推導出 Lambda 表達式的返回類型, 但并不是在所有的情況下都能實現. 即使編譯器能夠自動推導, 顯式地指定返回類型也能讓讀者更明了.

有時在已經出現了的函數參數列表之后指定返回類型, 能夠讓書寫更簡單, 也更易讀, 尤其是在返回類型依賴于模板參數時. 例如:

template auto add(T t, U u) -> decltype(t + u);

對比下面的例子:

template decltype(declval() + declval()) add(T t, U u);

缺點

后置返回類型相對來說是非常新的語法, 而且在 C 和 Java 中都沒有相似的寫法, 因此可能對讀者來說比較陌生.

在已有的代碼中有大量的函數聲明, 你不可能把它們都用新的語法重寫一遍. 因此實際的做法只能是使用舊的語法或者新舊混用. 在這種情況下, 只使用一種版本是相對來說更規整的形式.

結論

在大部分情況下, 應當繼續使用以往的函數聲明寫法, 即將返回類型置于函數名前. 只有在必需的時候 (如 Lambda 表達式) 或者使用后置語法能夠簡化書寫并且提高易讀性的時候才使用新的返回類型后置語法. 但是后一種情況一般來說是很少見的, 大部分時候都出現在相當復雜的模板代碼中, 而多數情況下不鼓勵寫這樣復雜的模板代碼.

5. 來自 Google 的奇技

Google 用了很多自己實現的技巧 / 工具使 C++ 代碼更加健壯, 我們使用 C++ 的方式可能和你在其它地方見到的有所不同.

5.1. 所有權與智能指針

> 總述

動態分配出的對象最好有單一且固定的所有主, 并通過智能指針傳遞所有權.

> 定義

所有權是一種登記／管理動態內存和其它資源的技術. 動態分配對象的所有主是一個對象或函數, 后者負責確保當前者無用時就自動銷毀前者. 所有權有時可以共享, 此時就由最后一個所有主來負責銷毀它. 甚至也可以不用共享, 在代碼中直接把所有權傳遞給其它對象.

智能指針是一個通過重載*和->運算符以表現得如指針一樣的類. 智能指針類型被用來自動化所有權的登記工作, 來確保執行銷毀義務到位.std::unique_ptr是 C++11 新推出的一種智能指針類型, 用來表示動態分配出的對象的獨一無二的所有權; 當std::unique_ptr離開作用域時, 對象就會被銷毀.std::unique_ptr不能被復制, 但可以把它移動（move）給新所有主.std::shared_ptr同樣表示動態分配對象的所有權, 但可以被共享, 也可以被復制; 對象的所有權由所有復制者共同擁有, 最后一個復制者被銷毀時, 對象也會隨著被銷毀.

> 優點

如果沒有清晰、邏輯條理的所有權安排, 不可能管理好動態分配的內存.

傳遞對象的所有權, 開銷比復制來得小, 如果可以復制的話.

傳遞所有權也比”借用”指針或引用來得簡單, 畢竟它大大省去了兩個用戶一起協調對象生命周期的工作.

如果所有權邏輯條理, 有文檔且不紊亂的話, 可讀性會有很大提升.

可以不用手動完成所有權的登記工作, 大大簡化了代碼, 也免去了一大波錯誤之惱.

對于 const 對象來說, 智能指針簡單易用, 也比深度復制高效.

> 缺點

不得不用指針（不管是智能的還是原生的）來表示和傳遞所有權. 指針語義可要比值語義復雜得許多了, 特別是在 API 里：這時不光要操心所有權, 還要顧及別名, 生命周期, 可變性以及其它大大小小的問題.

其實值語義的開銷經常被高估, 所以所有權傳遞帶來的性能提升不一定能彌補可讀性和復雜度的損失.

如果 API 依賴所有權的傳遞, 就會害得客戶端不得不用單一的內存管理模型.

如果使用智能指針, 那么資源釋放發生的位置就會變得不那么明顯.

std::unique_ptr的所有權傳遞原理是 C++11 的 move 語法, 后者畢竟是剛剛推出的, 容易迷惑程序員.

如果原本的所有權設計已經夠完善了, 那么若要引入所有權共享機制, 可能不得不重構整個系統.

所有權共享機制的登記工作在運行時進行, 開銷可能相當大.

某些極端情況下 (例如循環引用), 所有權被共享的對象永遠不會被銷毀.

智能指針并不能夠完全代替原生指針.

> 結論

如果必須使用動態分配, 那么更傾向于將所有權保持在分配者手中. 如果其他地方要使用這個對象, 最好傳遞它的拷貝, 或者傳遞一個不用改變所有權的指針或引用. 傾向于使用std::unique_ptr來明確所有權傳遞, 例如：

std::unique_ptr FooFactory();void FooConsumer(std::unique_ptr ptr);

如果沒有很好的理由, 則不要使用共享所有權. 這里的理由可以是為了避免開銷昂貴的拷貝操作, 但是只有當性能提升非常明顯, 并且操作的對象是不可變的（比如說std::shared_ptr）時候, 才能這么做. 如果確實要使用共享所有權, 建議于使用std::shared_ptr.

不要使用std::auto_ptr, 使用std::unique_ptr代替它.

5.2. Cpplint

> 總述

使用cpplint.py檢查風格錯誤.

> 說明

cpplint.py是一個用來分析源文件, 能檢查出多種風格錯誤的工具. 它不并完美, 甚至還會漏報和誤報, 但它仍然是一個非常有用的工具. 在行尾加//NOLINT, 或在上一行加//NOLINTNEXTLINE, 可以忽略報錯.

某些項目會指導你如何使用他們的項目工具運行cpplint.py. 如果你參與的項目沒有提供, 你可以單獨下載cpplint.py.

譯者（acgtyrant）筆記

把智能指針當成對象來看待的話, 就很好領會它與所指對象之間的關系了.

原來 Rust 的 Ownership 思想是受到了 C++ 智能指針的很大啟發啊.

scoped_ptr和auto_ptr已過時. 現在是shared_ptr和uniqued_ptr的天下了.

按本文來說, 似乎除了智能指針, 還有其它所有權機制, 值得留意.

Arch Linux 用戶注意了, AUR 有對 cpplint 打包.