天天看點

Google C++程式設計風格指南(三)

這一篇主要提到的是類,Lippman在《Inside The C++ Object Model 》第二章中對構造函數作了詳盡說明,本文中提到的幾個單詞基本仿該書中譯本侯捷先生的翻譯:

explicit:明确的

implicit:隐含的

trivial:沒有意義的

non-trivial:有意義的

原文位址:Google C++ Style Guide

類是C++中基本的代碼單元,自然被廣泛使用。本節列舉了在寫一個類時要做什麼、不要做什麼。

1. 構造函數(Constructor)的職責

構造函數中隻進行那些沒有實際意義的(trivial,譯者注:簡單初始化對于程式執行沒有實際的邏輯意義,因為成員變量的“有意義”的值大多不在構造函數中确定) 初始化,可能的話,使用Init()方法集中初始化為有意義的(non-trivial) 資料。

定義: 在構造函數中執行初始化操作。

優點: 排版友善,無需擔心類是否初始化。

缺點: 在構造函數中執行操作引起的問題有:

1) 構造函數中不易報告錯誤,不能使用異常。

2) 操作失敗會造成對象初始化失敗,引起不确定狀态。

3) 構造函數内調用虛函數,調用不會派發到子類實作中,即使目前沒有子類化實作,将來仍是隐患。

4) 如果有人建立該類型的全局變量(雖然違背了上節提到的規則),構造函數将在main()之前被調用,有可能破壞構造函數中暗含的假設條件。例如,gflags尚未初始化。

結論: 如果對象需要有意義的(non-trivial) 初始化,考慮使用另外的Init()方法并(或)增加一個成員标記用于訓示對象是否已經初始化成功。

2. 預設構造函數(Default Constructors)

如果一個類定義了若幹成員變量又沒有其他構造函數,需要定義一個預設構造函數,否則編譯器将自動生産預設構造函數。

定義: 建立一個沒有參數的對象時,預設構造函數被調用,當調用new[](為數組)時,預設構造函數總是被調用。

優點: 預設将結構體初始化為“不可能的”值,使調試更加容易。

缺點: 對代碼編寫者來說,這是多餘的工作。

結論:

如果類中定義了成員變量,沒有提供其他構造函數,你需要定義一個預設構造函數(沒有參數)。預設構造函數更适合于初始化對象,使對象内部狀态(internal state) 一緻、有效。

提供預設構造函數的原因是:如果你沒有提供其他構造函數,又沒有定義預設構造函數,編譯器将為你自動生成一個,編譯器生成的構造函數并不會對對象進行初始化。

如果你定義的類繼承現有類,而你又沒有增加新的成員變量,則不需要為新類定義預設構造函數。

3. 明确的構造函數(Explicit Constructors)

對單參數構造函數使用C++關鍵字explicit。

定義: 通常,隻有一個參數的構造函數可被用于轉換(conversion,譯者注:主要指隐式轉換,下文可見) , 例如,定義了Foo::Foo(string name),當向需要傳入一個Foo對象的函數傳入一個字元串時,構造函數Foo::Foo(string name)被調用并将該字元串轉換為一個Foo臨時對象傳給調用函數。看上去很友善,但如果你并不希望如此通過轉換生成一個新對象的話,麻煩也随之而來。 為避免構造函數被調用造成隐式轉換,可以将其聲明為explicit。

優點: 避免不合時宜的變換。

缺點: 無。

結論:

所有單參數構造函數必須是明确的。在類定義中,将關鍵字explicit加到單參數構造函數前:explicit Foo(string name);

例外:在少數情況下,拷貝構造函數可以不聲明為explicit;特意作為其他類的透明包裝器的類。類似例外情況應在注釋中明确說明。

4. 拷貝構造函數(Copy Constructors)

僅在代碼中需要拷貝一個類對象的時候使用拷貝構造函數;不需要拷貝時應使用

DISALLOW_COPY_AND_ASSIGN

定義: 通過拷貝建立對象時可使用拷貝構造函數(特别是對象的傳值時)。

優點: 拷貝構造函數使得拷貝對象更加容易,STL容器要求所有内容可拷貝、可指派。

缺點: C++中對象的隐式拷貝是導緻很多性能問題和bugs的根源。拷貝構造函數降低了代碼可讀性,相比按引用傳遞,跟蹤按值傳遞的對象更加困難,對象修改的地方變得難以捉摸。

結論:

大量的類并不需要可拷貝,也不需要一個拷貝構造函數或指派操作(assignment operator) 。不幸的是,如果你不主動聲明它們,編譯器會為你自動生成,而且是public的。

可以考慮在類的private中添加空的(dummy) 拷貝構造函數和指派操作,隻有聲明,沒有定義。由于這些空程式聲明為private,當其他代碼試圖使用它們的時候,編譯器将報錯。為了友善,可以使用宏DISALLOW_COPY_AND_ASSIGN:

// 禁止使用拷貝構造函數和指派操作的宏

// 應在類的private:中使用

#define DISALLOW_COPY_AND_ASSIGN(TypeName) /

  TypeName(const TypeName&);               /

  void operator=(const TypeName&)

class Foo {

public:

  Foo(int f);

  ~Foo();

private:

  DISALLOW_COPY_AND_ASSIGN(Foo);

};

如上所述,絕大多數情況下都應使用DISALLOW_COPY_AND_ASSIGN,如果類确實需要可拷貝,應在該類的頭檔案中說明原由,并适當定義拷貝構造函數和指派操作,注意在operator=中檢測自指派(self-assignment) 情況。

在将類作為STL容器值得時候,你可能有使類可拷貝的沖動。類似情況下,真正該做的是使用指針指向STL容器中的對象,可以考慮使用std::tr1::shared_ptr。

5. 結構體和類(Structs vs. Classes)

僅當隻有資料時使用struct,其它一概使用class。

在C++中,關鍵字struct和class幾乎含義等同,我們為其人為添加語義,以便為定義的資料類型合理選擇使用哪個關鍵字。

struct 被用在僅包含資料的消極對象(passive objects)上,可能包括有關聯的常量,但沒有存取資料成員之外的函數功能,而存取功能通過直接通路實作而無需方法調用,這兒提到的方法是指隻用于處 理資料成員的,如構造函數、析構函數、Initialize()、Reset()、Validate()。

如果需要更多的函數功能,class更适合,如果不确定的話,直接使用class。

如果與STL結合,對于仿函數(functors)和特性(traits) 可以不用class而是使用struct。

注意:類和結構體的成員變量使用不同的命名規則。

6. 繼承(Inheritance )

使用組合(composition,譯者注,這一點也是GoF在《Design Patterns》裡反複強調的) 通常比使用繼承更适宜,如果使用繼承的話,隻使用公共繼承。

定義: 當子類繼承基類時,子類包含了父基類所有資料及操作的定義。C++實踐中,繼承主要用于兩種場合:實作繼承(implementation inheritance) ,子類繼承父類的實作代碼;接口繼承(interface inheritance) ,子類僅繼承父類的方法名稱。

優點: 實作繼承通過原封不動的重用基類代碼減少了代碼量。由于繼承是編譯時聲明(compile-time declaration) ,編碼者和編譯器都可以了解相應操作并發現錯誤。接口繼承可用于程式上增強類的特定API的功能,在類沒有定義API的必要實作時,編譯器同樣可以偵錯。

缺點: 對于實作繼承,由于實作子類的代碼在父類和子類間延展,要了解其實作變得更加困難。子類不能重寫父類的非虛函數,當然也就不能修改其實作。基類也可能定義了一些資料成員,還要區分基類的實體輪廓(physical layout) 。

結論:

所有繼承必須是public的,如果想私有繼承的話,應該采取包含基類執行個體作為成員的方式作為替代。

不要過多使用實作繼承,組合通常更合适一些。努力做到隻在“是一個”("is-a",譯者注,其他"has-a"情況下請使用組合) 的情況下使用繼承:如果Bar的确“是一種”Foo,才令Bar是Foo的子類。

必要的話,令析構函數為virtual,必要是指,如果該類具有虛函數,其析構函數應該為虛函數。

譯者注:至于子類沒有額外資料成員,甚至父類也沒有任何資料成員的特殊情況下,析構函數的調用是否必要是語義争論,從程式設計設計規範的角度看,在含有虛函數的父類中,定義虛析構函數絕對必要。

限定僅在子類通路的成員函數為protected,需要注意的是資料成員應始終為私有。

當重定義派生的虛函數時,在派生類中明确聲明其為virtual。根本原因:如果遺漏virtual,閱讀者需要檢索類的所有祖先以确定該函數是否為虛函數(譯者注,雖然不影響其為虛函數的本質) 。

7. 多重繼承(Multiple Inheritance )

真正需要用到多重實作繼承(multiple implementation inheritance) 的時候非常少,隻有當最多一個基類中含有實作,其他基類都是以

Interface

為字尾的純接口類時才會使用多重繼承。

定義: 多重繼承允許子類擁有多個基類,要将作為純接口的基類和具有實作的基類差別開來。

優點: 相比單繼承,多重實作繼承可令你重用更多代碼。

缺點: 真正需要用到多重實作繼承的時候非常少,多重實作繼承看上去是不錯的解決方案,通常可以找到更加明确、清晰的、不同的解決方案。

結論: 隻有當所有超類(superclass) 除第一個外都是純接口時才能使用多重繼承。為確定它們是純接口,這些類必須以

Interface

為字尾。

注意:關于此規則,Windows下有種例外情況(譯者注,将在本譯文最後一篇的規則例外中闡述)。

8. 接口(Interface )

接口是指滿足特定條件的類,這些類以Interface為字尾(非必需)。

定義: 當一個類滿足以下要求時,稱之為純接口:

1) 隻有純虛函數("=0")和靜态函數(下文提到的析構函數除外);

2) 沒有非靜态資料成員;

3) 沒有定義任何構造函數。如果有,也不含參數,并且為protected;

4) 如果是子類,也隻能繼承滿足上述條件并以Interface為字尾的類。

接口類不能被直接執行個體化,因為它聲明了純虛函數。為確定接口類的所有實作可被正确銷毀,必須為之聲明虛析構函數(作為第1條規則的例外,析構函數不能是純虛函數)。具體細節可參考Stroustrup的《The C++ Programming Language, 3rd edition 》第12.4節。

優點: 以Interface為字尾可令他人知道不能為該接口類增加實作函數或非靜态資料成員,這一點對于多重繼承尤其重要。另外,對于Java程式員來說,接口的概念已經深入人心。

缺點: Interface字尾增加了類名長度,為閱讀和了解帶來不便,同時,接口特性作為實作細節不應暴露給客戶。

結論: 。隻有在滿足上述需要時,類才以Interface結尾,但反過來,滿足上述需要的類未必一定以Interface結尾。

9. 操作符重載(Operator Overloading )

除少數特定環境外,不要重載操作符。

定義: 一個類可以定義諸如+、/等操作符,使其可以像内建類型一樣直接使用。

優點: 使代碼看上去更加直覺,就像内建類型(如int)那樣,重載操作符使那些Equals()、Add()等黯淡無光的函數名好玩多了。為了使一些模闆函數正确工作,你可能需要定義操作符。

缺點: 雖然操作符重載令代碼更加直覺,但也有一些不足

1) 混淆直覺,讓你誤以為一些耗時的操作像内建操作那樣輕巧;

2) 查找重載操作符的調用處更加困難,查找Equals()顯然比同等調用==容易的多;

3) 有的操作符可以對指針進行操作,容易導緻bugs,Foo + 4做的是一件事,而&Foo + 4可能做的是完全不同的另一件事,對于二者,編譯器都不會報錯,使其很難調試;

4) 重載還有令你吃驚的副作用,比如,重載操作符&的類不能被前置聲明。

結論:

一般不要重載操作符,尤其是指派操作(operator=)比較陰險,應避免重載。如果需要的話,可以定義類似Equals()、CopyFrom()等函數。

然 而,極少數情況下需要重載操作符以便與模闆或“标準”C++類銜接(如operator<<(ostream&, const T&)),如果被證明是正當的尚可接受,但你要盡可能避免這樣做。尤其是不要僅僅為了在STL容器中作為key使用就重載operator==或 operator<,取而代之,你應該在聲明容器的時候,建立相等判斷和大小比較的仿函數類型。

有些STL算法确實需要重載operator==時可以這麼做,不要忘了提供文檔說明原因。

參考拷貝構造函數 和函數重載 。

10. 存取控制(Access Control )

将資料成員私有化,并提供相關存取函數,如定義變量foo_及取值函數foo()、指派函數set_foo()。

存取函數的定義一般内聯在頭檔案中。

參考繼承 和函數命名 。

11. 聲明次序(Declaration Order )

在類中使用特定的聲明次序:public:在private:之前,成員函數在資料成員(變量)前。

定義次序如下:public:、protected:、private:,如果那一塊沒有,直接忽略即可。

每一塊中,聲明次序一般如下:

1) typedefs和enums;

2) 常量;

3) 構造函數;

4) 析構函數;

5) 成員函數,含靜态成員函數;

6) 資料成員,含靜态資料成員。

宏DISALLOW_COPY_AND_ASSIGN置于private:塊之後,作為類的最後部分。參考拷貝構造函數 。

.cc檔案中函數的定義應盡可能和聲明次序一緻。

不要将大型函數内聯到類的定義中,通常,隻有那些沒有特别意義的或者性能要求高的,并且是比較短小的函數才被定義為内聯函數。更多細節參考譯文第一篇的 内聯函數 。

12. 編寫短小函數(Write Short Functions )

傾向于選擇短小、凝練的函數。

長函數有時是恰當的,是以對于函數長度并沒有嚴格限制。如果函數超過40行,可以考慮在不影響程式結構的情況下将其分割一下。

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

在處理代碼時,你可能會發現複雜的長函數,不要害怕修改現有代碼:如果證明這些代碼使用、調試困難,或者你需要使用其中的一小塊,考慮将其分割為更加短小、易于管理的若幹函數。

______________________________________

譯者:關于類的注意事項,總結一下:

1. 不在構造函數中做太多邏輯相關的初始化;

2. 編譯器提供的預設構造函數不會對變量進行初始化,如果定義了其他構造函數,編譯器不再提供,需要編碼者自行提供預設構造函數;

3. 為避免隐式轉換,需将單參數構造函數聲明為explicit;

4. 為避免拷貝構造函數、指派操作的濫用和編譯器自動生成,可目前聲明其為private且無需實作;

5. 僅在作為資料集合時使用struct;

6. 組合>實作繼承>接口繼承>私有繼承,子類重載的虛函數也要聲明virtual關鍵字,雖然編譯器允許不這樣做;

7. 避免使用多重繼承,使用時,除一個基類含有實作外,其他基類均為純接口;

8. 接口類類名以Interface為字尾,除提供帶實作的虛析構函數、靜态成員函數外,其他均為純虛函數,不定義非靜态資料成員,不提供構造函數,提供的話,聲明為protected;

9. 為降低複雜性,盡量不重載操作符,模闆、标準類中使用時提供文檔說明;

10. 存取函數一般内聯在頭檔案中;

11. 聲明次序:public->protected->private;

12. 函數體盡量短小、緊湊,功能單一。

繼續閱讀