• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            Creative Commons License
            本Blog采用 知識共享署名-非商業(yè)性使用-禁止演繹 3.0 Unported許可協(xié)議 進(jìn)行許可。 —— Fox <游戲人生>

            游戲人生

            游戲人生 != ( 人生 == 游戲 )
            站點遷移至:http://www.yulefox.com。請訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox
            posts - 62, comments - 508, trackbacks - 0, articles - 7

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

            explicit:明確的

            implicit:隱含的

            trivial:沒有意義的

            non-trivial:有意義的

             

            原文地址:

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

            1. 構(gòu)造函數(shù)(Constructor)的職責(zé)

            構(gòu)造函數(shù)中只進(jìn)行那些沒有實際意義的(trivial,譯者注:簡單初始化對于程序執(zhí)行沒有實際的邏輯意義,因為成員變量的“有意義”的值大多不在構(gòu)造函數(shù)中確定)初始化,可能的話,使用Init()方法集中初始化為有意義的(non-trivial)數(shù)據(jù)。

            定義:在構(gòu)造函數(shù)中執(zhí)行初始化操作。

            優(yōu)點:排版方便,無需擔(dān)心類是否初始化。

            缺點:在構(gòu)造函數(shù)中執(zhí)行操作引起的問題有:

            1) 構(gòu)造函數(shù)中不易報告錯誤,不能使用異常。

            2) 操作失敗會造成對象初始化失敗,引起不確定狀態(tài)。

            3) 構(gòu)造函數(shù)內(nèi)調(diào)用虛函數(shù),調(diào)用不會派發(fā)到子類實現(xiàn)中,即使當(dāng)前沒有子類化實現(xiàn),將來仍是隱患。

            4) 如果有人創(chuàng)建該類型的全局變量(雖然違背了上節(jié)提到的規(guī)則),構(gòu)造函數(shù)將在main()之前被調(diào)用,有可能破壞構(gòu)造函數(shù)中暗含的假設(shè)條件。例如,gflags尚未初始化。

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

            2. 默認(rèn)構(gòu)造函數(shù)(Default Constructors)

            如果一個類定義了若干成員變量又沒有其他構(gòu)造函數(shù),需要定義一個默認(rèn)構(gòu)造函數(shù),否則編譯器將自動生產(chǎn)默認(rèn)構(gòu)造函數(shù)。

            定義:新建一個沒有參數(shù)的對象時,默認(rèn)構(gòu)造函數(shù)被調(diào)用,當(dāng)調(diào)用new[](為數(shù)組)時,默認(rèn)構(gòu)造函數(shù)總是被調(diào)用。

            優(yōu)點:默認(rèn)將結(jié)構(gòu)體初始化為“不可能的”值,使調(diào)試更加容易。

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

            結(jié)論:

            如果類中定義了成員變量,沒有提供其他構(gòu)造函數(shù),你需要定義一個默認(rèn)構(gòu)造函數(shù)(沒有參數(shù))。默認(rèn)構(gòu)造函數(shù)更適合于初始化對象,使對象內(nèi)部狀態(tài)(internal state)一致、有效。

            提供默認(rèn)構(gòu)造函數(shù)的原因是:如果你沒有提供其他構(gòu)造函數(shù),又沒有定義默認(rèn)構(gòu)造函數(shù),編譯器將為你自動生成一個,編譯器生成的構(gòu)造函數(shù)并不會對對象進(jìn)行初始化。

            如果你定義的類繼承現(xiàn)有類,而你又沒有增加新的成員變量,則不需要為新類定義默認(rèn)構(gòu)造函數(shù)。

            3. 明確的構(gòu)造函數(shù)(Explicit Constructors)

            對單參數(shù)構(gòu)造函數(shù)使用C++關(guān)鍵字explicit。

            定義:通常,只有一個參數(shù)的構(gòu)造函數(shù)可被用于轉(zhuǎn)換(conversion,譯者注:主要指隱式轉(zhuǎn)換,下文可見),例如,定義了Foo::Foo(string name),當(dāng)向需要傳入一個Foo對象的函數(shù)傳入一個字符串時,構(gòu)造函數(shù)Foo::Foo(string name)被調(diào)用并將該字符串轉(zhuǎn)換為一個Foo臨時對象傳給調(diào)用函數(shù)。看上去很方便,但如果你并不希望如此通過轉(zhuǎn)換生成一個新對象的話,麻煩也隨之而來。為避免構(gòu)造函數(shù)被調(diào)用造成隱式轉(zhuǎn)換,可以將其聲明為explicit。

            優(yōu)點:避免不合時宜的變換。

            缺點:無。

            結(jié)論:

            所有單參數(shù)構(gòu)造函數(shù)必須是明確的。在類定義中,將關(guān)鍵字explicit加到單參數(shù)構(gòu)造函數(shù)前:explicit Foo(string name);

            例外:在少數(shù)情況下,拷貝構(gòu)造函數(shù)可以不聲明為explicit;特意作為其他類的透明包裝器的類。類似例外情況應(yīng)在注釋中明確說明。

            4. 拷貝構(gòu)造函數(shù)(Copy Constructors)

            僅在代碼中需要拷貝一個類對象的時候使用拷貝構(gòu)造函數(shù);不需要拷貝時應(yīng)使用DISALLOW_COPY_AND_ASSIGN

            定義:通過拷貝新建對象時可使用拷貝構(gòu)造函數(shù)(特別是對象的傳值時)。

            優(yōu)點:拷貝構(gòu)造函數(shù)使得拷貝對象更加容易,STL容器要求所有內(nèi)容可拷貝、可賦值。

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

            結(jié)論:

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

            可以考慮在類的private中添加空的(dummy)拷貝構(gòu)造函數(shù)和賦值操作,只有聲明,沒有定義。由于這些空程序聲明為private,當(dāng)其他代碼試圖使用它們的時候,編譯器將報錯。為了方便,可以使用宏DISALLOW_COPY_AND_ASSIGN:

            // 禁止使用拷貝構(gòu)造函數(shù)和賦值操作的宏
            // 應(yīng)在類的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);
            };

            如上所述,絕大多數(shù)情況下都應(yīng)使用DISALLOW_COPY_AND_ASSIGN,如果類確實需要可拷貝,應(yīng)在該類的頭文件中說明原由,并適當(dāng)定義拷貝構(gòu)造函數(shù)和賦值操作,注意在operator=中檢測自賦值(self-assignment)情況。

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

            5. 結(jié)構(gòu)體和類(Structs vs. Classes)

            僅當(dāng)只有數(shù)據(jù)時使用struct,其它一概使用class。

            在C++中,關(guān)鍵字struct和class幾乎含義等同,我們?yōu)槠淙藶樘砑诱Z義,以便為定義的數(shù)據(jù)類型合理選擇使用哪個關(guān)鍵字。

            struct被用在僅包含數(shù)據(jù)的消極對象(passive objects)上,可能包括有關(guān)聯(lián)的常量,但沒有存取數(shù)據(jù)成員之外的函數(shù)功能,而存取功能通過直接訪問實現(xiàn)而無需方法調(diào)用,這兒提到的方法是指只用于處理數(shù)據(jù)成員的,如構(gòu)造函數(shù)、析構(gòu)函數(shù)、Initialize()、Reset()、Validate()。

            如果需要更多的函數(shù)功能,class更適合,如果不確定的話,直接使用class。

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

            注意:類和結(jié)構(gòu)體的成員變量使用不同的命名規(guī)則。

            6. 繼承(Inheritance

            使用組合(composition,譯者注,這一點也是GoF在《Design Patterns》里反復(fù)強(qiáng)調(diào)的)通常比使用繼承更適宜,如果使用繼承的話,只使用公共繼承。

            定義:當(dāng)子類繼承基類時,子類包含了父基類所有數(shù)據(jù)及操作的定義。C++實踐中,繼承主要用于兩種場合:實現(xiàn)繼承(implementation inheritance),子類繼承父類的實現(xiàn)代碼;接口繼承(interface inheritance),子類僅繼承父類的方法名稱。

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

            缺點:對于實現(xiàn)繼承,由于實現(xiàn)子類的代碼在父類和子類間延展,要理解其實現(xiàn)變得更加困難。子類不能重寫父類的非虛函數(shù),當(dāng)然也就不能修改其實現(xiàn)。基類也可能定義了一些數(shù)據(jù)成員,還要區(qū)分基類的物理輪廓(physical layout)

            結(jié)論:

            所有繼承必須是public的,如果想私有繼承的話,應(yīng)該采取包含基類實例作為成員的方式作為替代。

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

            必要的話,令析構(gòu)函數(shù)為virtual,必要是指,如果該類具有虛函數(shù),其析構(gòu)函數(shù)應(yīng)該為虛函數(shù)。

            譯者注:至于子類沒有額外數(shù)據(jù)成員,甚至父類也沒有任何數(shù)據(jù)成員的特殊情況下,析構(gòu)函數(shù)的調(diào)用是否必要是語義爭論,從編程設(shè)計規(guī)范的角度看,在含有虛函數(shù)的父類中,定義虛析構(gòu)函數(shù)絕對必要。

            限定僅在子類訪問的成員函數(shù)為protected,需要注意的是數(shù)據(jù)成員應(yīng)始終為私有。

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

            7. 多重繼承(Multiple Inheritance

            真正需要用到多重實現(xiàn)繼承(multiple implementation inheritance)的時候非常少,只有當(dāng)最多一個基類中含有實現(xiàn),其他基類都是以Interface為后綴的純接口類時才會使用多重繼承。

            定義:多重繼承允許子類擁有多個基類,要將作為純接口的基類和具有實現(xiàn)的基類區(qū)別開來。

            優(yōu)點:相比單繼承,多重實現(xiàn)繼承可令你重用更多代碼。

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

            結(jié)論:只有當(dāng)所有超類(superclass)除第一個外都是純接口時才能使用多重繼承。為確保它們是純接口,這些類必須以Interface為后綴。

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

            8. 接口(Interface

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

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

            1) 只有純虛函數(shù)("=0")和靜態(tài)函數(shù)(下文提到的析構(gòu)函數(shù)除外);

            2) 沒有非靜態(tài)數(shù)據(jù)成員;

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

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

            接口類不能被直接實例化,因為它聲明了純虛函數(shù)。為確保接口類的所有實現(xiàn)可被正確銷毀,必須為之聲明虛析構(gòu)函數(shù)(作為第1條規(guī)則的例外,析構(gòu)函數(shù)不能是純虛函數(shù))。具體細(xì)節(jié)可參考Stroustrup的《The C++ Programming Language, 3rd edition》第12.4節(jié)。

            優(yōu)點:以Interface為后綴可令他人知道不能為該接口類增加實現(xiàn)函數(shù)或非靜態(tài)數(shù)據(jù)成員,這一點對于多重繼承尤其重要。另外,對于Java程序員來說,接口的概念已經(jīng)深入人心。

            缺點:Interface后綴增加了類名長度,為閱讀和理解帶來不便,同時,接口特性作為實現(xiàn)細(xì)節(jié)不應(yīng)暴露給客戶。

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

            9. 操作符重載(Operator Overloading

            除少數(shù)特定環(huán)境外,不要重載操作符。

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

            優(yōu)點:使代碼看上去更加直觀,就像內(nèi)建類型(如int)那樣,重載操作符使那些Equals()、Add()等黯淡無光的函數(shù)名好玩多了。為了使一些模板函數(shù)正確工作,你可能需要定義操作符。

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

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

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

            3) 有的操作符可以對指針進(jìn)行操作,容易導(dǎo)致bugs,F(xiàn)oo + 4做的是一件事,而&Foo + 4可能做的是完全不同的另一件事,對于二者,編譯器都不會報錯,使其很難調(diào)試;

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

            結(jié)論:

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

            然而,極少數(shù)情況下需要重載操作符以便與模板或“標(biāo)準(zhǔn)”C++類銜接(如operator<<(ostream&, const T&)),如果被證明是正當(dāng)?shù)纳锌山邮埽阋M可能避免這樣做。尤其是不要僅僅為了在STL容器中作為key使用就重載operator==或operator<,取而代之,你應(yīng)該在聲明容器的時候,創(chuàng)建相等判斷和大小比較的仿函數(shù)類型。

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

            參考拷貝構(gòu)造函數(shù)函數(shù)重載

            10. 存取控制(Access Control

            將數(shù)據(jù)成員私有化,并提供相關(guān)存取函數(shù),如定義變量foo_及取值函數(shù)foo()、賦值函數(shù)set_foo()。

            存取函數(shù)的定義一般內(nèi)聯(lián)在頭文件中。

            參考繼承函數(shù)命名

            11. 聲明次序(Declaration Order

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

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

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

            1) typedefs和enums;

            2) 常量;

            3) 構(gòu)造函數(shù);

            4) 析構(gòu)函數(shù);

            5) 成員函數(shù),含靜態(tài)成員函數(shù);

            6) 數(shù)據(jù)成員,含靜態(tài)數(shù)據(jù)成員。

            宏DISALLOW_COPY_AND_ASSIGN置于private:塊之后,作為類的最后部分。參考拷貝構(gòu)造函數(shù)

            .cc文件中函數(shù)的定義應(yīng)盡可能和聲明次序一致。

            不要將大型函數(shù)內(nèi)聯(lián)到類的定義中,通常,只有那些沒有特別意義的或者性能要求高的,并且是比較短小的函數(shù)才被定義為內(nèi)聯(lián)函數(shù)。更多細(xì)節(jié)參考譯文第一篇的內(nèi)聯(lián)函數(shù)

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

            傾向于選擇短小、凝練的函數(shù)。

            長函數(shù)有時是恰當(dāng)?shù)模虼藢τ诤瘮?shù)長度并沒有嚴(yán)格限制。如果函數(shù)超過40行,可以考慮在不影響程序結(jié)構(gòu)的情況下將其分割一下。

            即使一個長函數(shù)現(xiàn)在工作的非常好,一旦有人對其修改,有可能出現(xiàn)新的問題,甚至導(dǎo)致難以發(fā)現(xiàn)的bugs。使函數(shù)盡量短小、簡單,便于他人閱讀和修改代碼。

            在處理代碼時,你可能會發(fā)現(xiàn)復(fù)雜的長函數(shù),不要害怕修改現(xiàn)有代碼:如果證實這些代碼使用、調(diào)試?yán)щy,或者你需要使用其中的一小塊,考慮將其分割為更加短小、易于管理的若干函數(shù)。

            ______________________________________

            譯者:關(guān)于類的注意事項,總結(jié)一下:

            1. 不在構(gòu)造函數(shù)中做太多邏輯相關(guān)的初始化;

            2. 編譯器提供的默認(rèn)構(gòu)造函數(shù)不會對變量進(jìn)行初始化,如果定義了其他構(gòu)造函數(shù),編譯器不再提供,需要編碼者自行提供默認(rèn)構(gòu)造函數(shù);

            3. 為避免隱式轉(zhuǎn)換,需將單參數(shù)構(gòu)造函數(shù)聲明為explicit;

            4. 為避免拷貝構(gòu)造函數(shù)、賦值操作的濫用和編譯器自動生成,可目前聲明其為private且無需實現(xiàn);

            5. 僅在作為數(shù)據(jù)集合時使用struct;

            6. 組合>實現(xiàn)繼承>接口繼承>私有繼承,子類重載的虛函數(shù)也要聲明virtual關(guān)鍵字,雖然編譯器允許不這樣做;

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

            8. 接口類類名以Interface為后綴,除提供帶實現(xiàn)的虛析構(gòu)函數(shù)、靜態(tài)成員函數(shù)外,其他均為純虛函數(shù),不定義非靜態(tài)數(shù)據(jù)成員,不提供構(gòu)造函數(shù),提供的話,聲明為protected;

            9. 為降低復(fù)雜性,盡量不重載操作符,模板、標(biāo)準(zhǔn)類中使用時提供文檔說明;

            10. 存取函數(shù)一般內(nèi)聯(lián)在頭文件中;

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

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

            Feedback

            # re: [譯]Google C++編程風(fēng)格指南(三)  回復(fù)  更多評論   

            2008-07-17 18:05 by 陳梓瀚(vczh)
            構(gòu)造函數(shù)可以throw,不知道為什么不能用異常。構(gòu)造函數(shù)失敗的時候要讓那個對象從此不能被訪問到才對,所以用throw。

            # re: [譯]Google C++編程風(fēng)格指南(三)  回復(fù)  更多評論   

            2008-07-18 10:06 by Fox
            這一點在下一篇C++特性中有對禁止使用C++異常的說明,不僅僅是針對構(gòu)造函數(shù),是針對整個coding。
            不管怎么說,都只是一種編程約束,有利必有弊,感覺更多是從軟件工程的角度給出的約束。

            # re: [譯]Google C++編程風(fēng)格指南(三)  回復(fù)  更多評論   

            2008-07-19 12:52 by 陳梓瀚(vczh)
            原來是文章中的c++不是c++,只是more powerful c而已。

            throw的確是有利有弊的,不過禁止光了那也不好。當(dāng)異常真的需要在調(diào)用堆棧中一級以及傳播出來的時候,自己搞是很慘的。

            # re: [譯]Google C++編程風(fēng)格指南(三)  回復(fù)  更多評論   

            2008-07-19 13:48 by Fox
            恩,看過這個指南之后,感覺是因為Google的項目中大多沒有使用高級C++特性,所以對于很多特性都是盡量避免使用,對于自己開發(fā)的項目制定一個自己的風(fēng)格,大家一起遵循,也基本是從軟件工程的角度,我比較贊成在底層模塊中使用,上層邏輯可以少用即可。
            中文成人无码精品久久久不卡 | 国产午夜福利精品久久2021| 久久亚洲综合色一区二区三区| 99久久国产精品免费一区二区| 久久久久人妻精品一区三寸蜜桃| 久久精品国产精品青草| 久久精品国产精品国产精品污| 精品久久久久久无码中文字幕一区| 久久久亚洲AV波多野结衣| 久久久久久亚洲精品影院| 亚洲国产成人久久综合区| 一级a性色生活片久久无少妇一级婬片免费放 | .精品久久久麻豆国产精品| 久久婷婷成人综合色综合| 国产一区二区精品久久| 国产精品久久自在自线观看| 99久久中文字幕| 精品久久人人做人人爽综合 | 久久影院午夜理论片无码| 欧美精品一区二区久久| 久久热这里只有精品在线观看| 久久精品国产亚洲AV香蕉| 久久ZYZ资源站无码中文动漫| 久久99精品久久久久久动态图| 久久精品国产一区二区三区日韩| 久久91这里精品国产2020| 久久无码中文字幕东京热| 97久久超碰国产精品旧版| 国产精品无码久久四虎| 亚洲人成网亚洲欧洲无码久久| 久久Av无码精品人妻系列| 狠狠色伊人久久精品综合网| 亚洲精品成人网久久久久久| 亚洲精品乱码久久久久66| 国产A级毛片久久久精品毛片| 亚洲日本久久久午夜精品| 精品久久久噜噜噜久久久 | 久久久久久久综合日本| 色欲久久久天天天综合网精品| 国内精品久久久久久久亚洲| 久久精品亚洲一区二区三区浴池|