青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

羅朝輝(飄飄白云)

關(guān)注嵌入式操作系統(tǒng),移動平臺,圖形開發(fā)。-->加微博 ^_^

  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
  85 隨筆 :: 0 文章 :: 169 評論 :: 0 Trackbacks

[深入理解C++(二)]理解接口繼承規(guī)則

 羅朝輝 ( http://m.shnenglu.com/kesalin/ )

CC許可,轉(zhuǎn)載請注明出處

一,前言

在前一篇《[深入理解C++(一)]類型轉(zhuǎn)換(Type Casting)》中,我詳細(xì)講述了 C++ 中轉(zhuǎn)型動作,以及使用規(guī)則。有網(wǎng)友說應(yīng)該提及下《深度探索 C++ 對象模型》一書中的內(nèi)容,其實他的意思是,要是對 C++ 對象的內(nèi)存布局不甚了解,就想要徹悟C++中的類型轉(zhuǎn)型,對象切割,虛函數(shù)調(diào)用等,猶如脫離了堅實的根基,想去建空中閣樓。理解 C++ 對象的內(nèi)存布局對學(xué)會 C++來說至關(guān)重要,但我不打算寫 C++ 對象的內(nèi)存布局相關(guān)的文章,因為要站在前人的肩膀上,大牛陳皓 已經(jīng)就這個主題寫了三篇圖文并茂的文章:

(一),C++ 虛函數(shù)表解析

(二),C++ 對象的內(nèi)存布局(上)

(三),C++ 對象的內(nèi)存布局(下)

 

在繼續(xù)閱讀本文之前,建議先閱讀這三篇文章,以更好地理解本系列文章。在接下來的內(nèi)容中,我將從重載,重寫,屏蔽等概念入手,引入眾多接口繼承規(guī)則。

 

二,引子:重載(overload),重寫(override),屏蔽(hide)

重載(overload):在相同作用域內(nèi),函數(shù)名稱相同,參數(shù)或常量性(const)不同的相關(guān)函數(shù)稱為重載。重載函數(shù)之間的區(qū)分主要在參數(shù)和常量性(const)的不同上,若僅僅是返回值或修飾符 virtual,public/protected/private的不同不被視為重載函數(shù)(無法通過編譯)。不同參數(shù)是指參數(shù)的個數(shù)或類型不同,而類型不同是指各類型之間不能進(jìn)行隱身類型轉(zhuǎn)換或不多于一次的用戶自定義類型轉(zhuǎn)換(關(guān)于類型轉(zhuǎn)換,請參考前文:類型轉(zhuǎn)型(Type Casting))。當(dāng)調(diào)用發(fā)生時,編譯器在進(jìn)行重載決議時根據(jù)調(diào)用所提供的參數(shù)來選擇最佳匹配的函數(shù)。

重寫(override):派生類重寫基類中同名同參數(shù)同返回值的函數(shù)(通常是虛函數(shù),這是推薦的做法)。同樣重寫的函數(shù)可以有不同的修飾符virtual,public/protected/private。

屏蔽(hide):一個內(nèi)部作用域(派生類,嵌套類或名字空間)內(nèi)提供一個同名但不同參數(shù)或不同常量性(const)的函數(shù),使得外圍作用域的同名函數(shù)在內(nèi)部作用域不可見,編譯器在進(jìn)行名字查找時將在內(nèi)部作用域找到該名字從而停止去外圍作用域查找,因而屏蔽外圍作用域的同名函數(shù)。

(注:編譯器在決定哪一個函數(shù)應(yīng)該被調(diào)用時,依次要做三件事:名字查找,重載決議,訪問性檢查。后續(xù)文章將詳細(xì)介紹這個決定過程。)

下面來分析示例:

class Base
{
public:
    virtual void f() { cout << "Base::f()" << endl; }
    void f(int) { cout << "Base::f(int)" << endl; }
    virtual void f(intconst { cout << "Base::f(int) const" << endl; }
    virtual void f(int *) { cout << "Base::f(int *)" << endl; }
};

class Derived : public Base
{
public:
    virtual void f() { cout << "Derived::f()" << endl; }
    virtual void f(char) { cout << "Derived::f(char)" << endl; }
};
const Base b;
b.f(10);

Derived d;
int value = 10;

d.f();
d.f('A');
d.f(10);
//d.f(&value);//編譯報錯

 

在上面代碼中,Base 中的一系列名為 f 的函數(shù)在同一作用域內(nèi),且同名不同參或不同常量性,故為重載函數(shù);而 Derived 中的 f() 則是重寫了基類同名同參的 f();而 Derived 中的 f(char) 則屏蔽了 Base 中所有的同名函數(shù)。

所以上面代碼的執(zhí)行結(jié)果是:

Base::f(int) const
Derived::f()
Derived::f(char)
Derived::f(char)

對 d.f(10); 這兩個調(diào)用,看似基類 Base 中有更好的匹配,但實際上由于編譯器在進(jìn)行名字查找時,首先在 Derived 類作用域中進(jìn)行查找,找到  f(char) 就停止去基類作用域中查找,因而基類的所有同名函數(shù)沒有機(jī)會進(jìn)入重載決議,因而被屏蔽了。因此編譯器將 10 隱式轉(zhuǎn)型為 char 調(diào)用 Derived 中的 f(char)。至此,聰明的你應(yīng)該很容易明白為什么 d.f(&value);  無法通過編譯了吧(VS編譯器的提示信息很給力)。

 

三,函數(shù)繼承規(guī)則:

鑒于繼承基類的函數(shù)有如此隱晦的概念需要弄懂,再加上 virtual 函數(shù),public/protected/private 繼承等等,更是增加了理解一個類接口的難度(因為你不僅要看類自身的接口,還有向上追溯所有基類的接口,以及是以何種方式繼承基類的接口等等)。因此,C++里面有很多針對類接口繼承的慣用法:

1,優(yōu)先使用組合而非繼承。既然繼承代價如此之大,那么最好的就是不繼承唄。當(dāng)然不是說完全不用繼承,只有在存在明確的“IS-A”關(guān)系時,繼承的好處才會顯現(xiàn)出來(可以用多態(tài)-但要遵循 Liskov 替換原則);而其他情況下(”HAS-A”或“Is-implemented-in-terms-of”)應(yīng)毫不猶豫地使用組合,而且要優(yōu)先使用 PIMPL(Point to implementation) 手法(后續(xù)文章會介紹這個慣用法)來使用組合。

2,純虛函數(shù)繼承規(guī)則-聲明純虛函數(shù)的目的是讓派生類來繼承函數(shù)接口而非實現(xiàn),使得純虛函數(shù)就像Java或C#中的 interface 一樣。唯一的例外就是需要純析構(gòu)函數(shù)提供實現(xiàn)(避免資源泄漏)。

3,非純虛函數(shù)繼承規(guī)則-聲明非純虛函數(shù)的目的是讓派生類繼承函數(shù)接口及默認(rèn)實現(xiàn)。但這是一種欠佳的做法,因為默認(rèn)實現(xiàn)能讓新加入的沒有重寫該實現(xiàn)的派生類通過編譯并運行,而默認(rèn)實現(xiàn)有可能并不適用于新加入的派生類,對此編譯器并不會提供任何信息(警告都沒一個)。為了應(yīng)對這一潛在的陷阱,誕生了另一個規(guī)則:”純虛函數(shù)的聲明提供接口,純虛函數(shù)的實現(xiàn)提供默認(rèn)實現(xiàn);派生類必須重寫該接口,但在實現(xiàn)時可以調(diào)用基類的默認(rèn)實現(xiàn)。“

如下代碼所示:

class Base
{
public:
    virtual void f() = 0;
};

void Base::f()
{
    cout << "Base::f() default implement." << endl;
}

class DerivedA : public Base
{
public:
    virtual void f()
    {
        Base::f();
    }
};

class DerivedB : public Base
{
public:
    virtual void f()
    {
        cout << "DerivedB::f() override." << endl;
    }
};

4,非虛函數(shù)繼承規(guī)則-永遠(yuǎn)也不要重寫基類中的非虛函數(shù)。非虛函數(shù)的目的就是為了讓派生類繼承基類的強制性實現(xiàn),它并不希望被派生類改寫。

5,盡量不要屏蔽外圍作用域(包括繼承而來的)名字。屏蔽所帶來的隱晦難以理解等問題在前面已有描述。

如果沒得選擇(我還真沒想到有什么場景會出現(xiàn)這種情況,通常換個名字都是可行的)必須重新定義或重寫基類中同名函數(shù),那么你應(yīng)該為每一個原本會被隱藏的名字引入一個 using 聲明或使用轉(zhuǎn)交函數(shù)(派生類定義同名同參函數(shù),在該函數(shù)內(nèi)部調(diào)用基類的同名同參函數(shù))來使這些名字在派生類的作用域中可見。(Effective C++ 條款33)。

該規(guī)則應(yīng)用如下:

class Base
{
public:
    virtual void f() { cout << "Base::f()" << endl; }
    void f(int) { cout << "Base::f(int)" << endl; }
    virtual void f(intconst { cout << "Base::f(int) const" << endl; }
    virtual void f(int *) { cout << "Base::f(int *)" << endl; }
};

class Derived : public Base
{
public:
    using Base::f;
    virtual void f() { cout << "Derived::f()" << endl; }
    //virtual void f(char) { cout << "Derived::f(char)" << endl; }
};
const Base b;
b.f(10);

Derived d;
int value = 10;

d.f();
d.f('A');
d.f(10);
d.f(&value);

 

運行得到的結(jié)果為:

Base::f(int) const
Derived::f()
Base::f(int)
Base::f(int)
Base::f(int *)

在這里,因為使用了 using Base::f; ,因此基類中的所有名字 f 對子類來說都是可見的,所有 d.f(&value); 等均可通過編譯運行了。再次提醒:這是一種非常不好的做法。

6,基類的析構(gòu)函數(shù)應(yīng)當(dāng)為虛函數(shù),以避免資源泄漏。

假設(shè)有如下情況,帶非虛析構(gòu)函數(shù)的基類指針 pb 指向一個派生類對象 d,而派生類在其析構(gòu)函數(shù)中釋放了一些資源,如果我們 delete pb; 那么派生類對象的析構(gòu)函數(shù)就不會被調(diào)用,從而導(dǎo)致資源泄漏發(fā)生。因此,應(yīng)該聲明基類的析構(gòu)函數(shù)為虛函數(shù)。

7,避免 private 繼承 – private 繼承通常意味著根據(jù)某物實現(xiàn)出(Is-implemented-in-terms-of),此種情況下使用基類與派生類這樣的術(shù)語并不太合適,因為它不滿足 Liskov 替換原則,并且從基類繼承而來的所有接口均為私有的,外部不可訪問。private 繼承可用 PIMPL 手法取代。

文中已經(jīng)兩次提到 PIMPL 利器,在這里就 private 繼承先給出一個示例,以后再詳述 PIMPL 的好處。

原先使用 private 繼承:

class SomeClass
{
public:
    void DoSomething(){}
};

class OtherClass : private SomeClass
{
private:
    void DoSomething(){}
};

使用 PIMPL 手法替代:

class SomeClass
{
public:
    void DoSomething(){}
};

class OtherClass
{
public:
    OtherClass();
    ~OtherClass();

    void DoSomething();
private:
    SomeClass * pImpl;
};

OtherClass::OtherClass()
{
    pImpl = new SomeClass();
}

OtherClass::~OtherClass()
{
    delete pImpl;
}

void OtherClass::DoSomething()
{
    pImpl->DoSomething();
}

8,不要改寫繼承而來的缺省參數(shù)值。前面已經(jīng)說到非虛函數(shù)繼承是種不好的做法,所以在這里的焦點就放在繼承一個帶有缺省參數(shù)值的虛函數(shù)上了。為什么改寫繼承而來的缺省參數(shù)值不好呢?因為虛函數(shù)是動態(tài)綁定的,而缺省參數(shù)值卻是靜態(tài)綁定的,這樣你在進(jìn)行多態(tài)調(diào)用時:函數(shù)是由動態(tài)類型決定的,而其缺省參數(shù)卻是由靜態(tài)類型決定的,違反直覺。

有代碼有真相:

class Base
{
public:
    // 前面的示例為了簡化代碼沒有遵循虛析構(gòu)函數(shù)規(guī)則,在這里說明下
    virtual ~Base() {}; 
    virtual void f(int defaultValue = 10)
    {
        cout << "Base::f() value = " << defaultValue << endl;
    }
};

class Derived : public Base
{
public:
    virtual void f(int defaultValue = 20)
    {
        cout << "Derived::f() value = " << defaultValue << endl;
    }
};

這段代碼的輸出為:

Derived::f() value = 10

調(diào)用的是動態(tài)類型 d -派生類 Derived的函數(shù)接口,但缺省參數(shù)值卻是由靜態(tài)類型 pb-基類 Base 的函數(shù)接口決定的,這等隱晦的細(xì)節(jié)很可能會浪費你一下午來調(diào)試,所以還是早點預(yù)防為好。

9,還有一種流派認(rèn)為不應(yīng)公開(public)除虛析構(gòu)函數(shù)之外的虛函數(shù)接口,而應(yīng)公開一個非虛函數(shù),在該非虛函數(shù)內(nèi) protected/private 的虛函數(shù)。這種做法是將接口何時被調(diào)用(非虛函數(shù))與接口如何被實現(xiàn)(虛函數(shù))分離開來,以達(dá)到更好的隔離效果。在設(shè)計模式上,這是一種策略模式。通常在非虛函數(shù)內(nèi)內(nèi)聯(lián)調(diào)用(直接在頭文件函數(shù)申明處實現(xiàn)就能達(dá)到此效果)虛函數(shù),所以在效率上與直接調(diào)用虛函數(shù)相比不相上下。

譬如:

class Base
{
public:
    virtual ~Base() {}
    
    void DoSomething()
    {
        StepOne();
        StepTwo();
    }
private:
    virtual void StepOne() = 0;
    virtual void StepTwo() = 0;
};

class Derived : public Base
{
private:
    virtual void StepOne()
    {
        cout << "Derived StepOne: do something." << endl;
    }
    virtual void StepTwo()
    {
        cout << "Derived StepTwo: do something." << endl;
    }
};

 

四,后記

C++ 陷阱特別多,學(xué)好用好 C++ 不容易,但只要把 OO 設(shè)計原則牢記在心頭,多見識些 C++ 慣用手法,C++ 的威力就能很好的展現(xiàn)出來。

 

五,引用

Effective C++ 條款 32 ~ 39

More Effective C++ 條款20 ~ 25







posted on 2012-11-06 21:21 羅朝輝 閱讀(3260) 評論(5)  編輯 收藏 引用 所屬分類: C/C++

評論

# re: [深入理解C++(二)]理解接口繼承規(guī)則 2012-11-07 13:47 3tgame
"在上面代碼中,Base 中的一系列名為 f 的函數(shù)在同一作用域內(nèi),且同名不同參或不同常量性,故為重載函數(shù);而 Derived 中的 f() 則是重寫了基類同名同參的 f();而 Derived 中的 f(char) 則屏蔽了 Base 中所有的同名函數(shù)。"

我怎么都找不到本文第一段程序哪里出現(xiàn)這個f(char) 函數(shù)?  回復(fù)  更多評論
  

# re: [深入理解C++(二)]理解接口繼承規(guī)則 2012-11-07 15:42 羅朝輝
@3tgame

多謝提醒,已經(jīng)修改了。  回復(fù)  更多評論
  

# re: [深入理解C++(二)]理解接口繼承規(guī)則[未登錄] 2012-11-08 14:28 歲月漫步
C++中細(xì)節(jié)太多了  回復(fù)  更多評論
  

# re: [深入理解C++(二)]理解接口繼承規(guī)則 2013-09-13 16:39 李明
mark下!  回復(fù)  更多評論
  

# re: [深入理解C++(二)]理解接口繼承規(guī)則 2014-01-15 16:43 ss
最后一個例子, " 在設(shè)計模式上,這是一種策略模式 ".
我怎么看怎么像是 Template Method.

現(xiàn)在學(xué)著學(xué)著, 很多設(shè)計模式我都已經(jīng)分辨不出來了... :(  回復(fù)  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲黄色在线观看| 久久久精品午夜少妇| 欧美视频一区二区三区…| 久久久久国产成人精品亚洲午夜| 亚洲天堂av图片| 亚洲特级毛片| 欧美夜福利tv在线| 美女图片一区二区| 欧美日本视频在线| 国产精品美女www爽爽爽视频| 欧美亚洲成人网| 国产日产亚洲精品| 亚洲精品资源| 久久www免费人成看片高清 | 国产在线精品一区二区中文| 国产亚洲精品一区二区| 亚洲国产精品va在线看黑人| 在线视频亚洲| 久久免费视频网| 亚洲精品中文字幕女同| 午夜视频一区| 欧美片第1页综合| 国产一区激情| 亚洲一级片在线看| 欧美成人综合网站| 亚洲在线日韩| 激情五月综合色婷婷一区二区| 激情亚洲一区二区三区四区| 亚洲一区二区三区久久| 久久中文在线| 亚洲一区二区三区乱码aⅴ| 亚洲欧美资源在线| 久久久久久久欧美精品| 亚洲最新在线| 亚洲大片在线| 欧美片网站免费| 狠狠爱www人成狠狠爱综合网| 亚洲精品少妇30p| 久久精品午夜| 亚洲图片欧美一区| 欧美另类人妖| 亚洲动漫精品| 久久精品在线视频| 亚洲伊人久久综合| 欧美日一区二区三区在线观看国产免| 亚洲电影下载| 裸体一区二区三区| 久久激情视频久久| 国产视频在线观看一区二区| 亚洲专区一区| 中文精品视频| 国产精品乱人伦一区二区| 一区二区高清视频| 亚洲狠狠丁香婷婷综合久久久| 久久精精品视频| 国产在线播放一区二区三区| 欧美一区二区在线观看| 亚洲小视频在线观看| 欧美久久电影| 亚洲视频一二| 亚洲一区二区三区在线观看视频| 国产精品hd| 亚洲欧美日韩国产| 午夜精彩视频在线观看不卡| 国产乱码精品一区二区三区不卡| 欧美日韩网址| 一区二区毛片| 亚洲午夜在线观看| 国产日韩在线一区二区三区| 欧美在线播放| 久久国内精品自在自线400部| 狠狠色丁香久久婷婷综合丁香| 久久亚裔精品欧美| 欧美a级片网站| 日韩视频不卡中文| 一区二区三区日韩在线观看| 国产精品久久久久久久免费软件 | 久久久久久久91| 久久久久久一区二区| 亚洲电影下载| 亚洲视频中文字幕| 极品少妇一区二区三区精品视频| 欧美高清在线精品一区| 欧美日韩蜜桃| 久久亚洲精品视频| 欧美伦理91i| 久久久青草青青国产亚洲免观| 免费看亚洲片| 亚洲欧美一区二区视频| 久久免费精品日本久久中文字幕| 亚洲乱码国产乱码精品精天堂| 亚洲一区二区三区欧美 | 国产亚洲激情视频在线| 久久久久久久国产| 欧美精品日韩www.p站| 亚洲女同精品视频| 久久久视频精品| 亚洲视频一区在线观看| 久久天堂成人| 久久国产福利| 欧美三级午夜理伦三级中视频| 久久人人超碰| 国产精品久久久久aaaa| 欧美成人国产va精品日本一级| 国产精品扒开腿爽爽爽视频| 欧美波霸影院| 国产午夜精品一区二区三区视频| 亚洲精品久久嫩草网站秘色| 国产亚洲精品激情久久| 一本色道久久综合精品竹菊| 亚洲福利视频三区| 欧美影院午夜播放| 亚洲欧美日韩国产成人| 欧美大片在线看| 久久这里只精品最新地址| 国产精品爽爽爽| 一区二区免费在线播放| 亚洲日本乱码在线观看| 亚洲一区二区在线看| 欧美激情国产精品| 狂野欧美性猛交xxxx巴西| 国产精品久久久久久久久久妞妞| 欧美激情国产日韩精品一区18| 国产精品网站在线播放| 亚洲神马久久| 亚洲天堂男人| 欧美日韩国产成人在线91| 亚洲国产精品成人va在线观看| 今天的高清视频免费播放成人| 亚洲欧美日韩精品久久久久| 午夜精品网站| 国产精品天天摸av网| 亚洲一区二区少妇| 小黄鸭视频精品导航| 国产精品素人视频| 午夜激情一区| 久久久久久免费| 伊人成年综合电影网| 久久亚洲国产成人| 欧美成人情趣视频| 亚洲国产日韩欧美在线99| 免费永久网站黄欧美| 最新精品在线| 亚洲欧美日韩天堂| 国产免费一区二区三区香蕉精| 亚洲一区二区三区乱码aⅴ蜜桃女 亚洲一区二区三区乱码aⅴ | 日韩亚洲欧美一区二区三区| 99国产精品国产精品毛片| 欧美激情精品久久久久久久变态| 亚洲国语精品自产拍在线观看| 99视频国产精品免费观看| 欧美日韩蜜桃| 欧美一区二区免费| 欧美jizz19hd性欧美| 99re8这里有精品热视频免费 | 亚洲大胆视频| 久久激情视频| 亚洲第一在线视频| 亚洲视频在线播放| 国产一区二区高清不卡| 久久视频精品在线| 亚洲精品在线视频观看| 欧美亚洲在线播放| 在线观看成人av| 欧美日韩一区二区视频在线 | 国产精品视频yy9099| 久久精品五月婷婷| 亚洲欧洲精品一区二区三区| 亚洲在线观看视频网站| 有码中文亚洲精品| 欧美午夜精品| 老司机精品视频一区二区三区| 在线中文字幕一区| 亚洲成色777777女色窝| 欧美成人一区二区三区| 99热精品在线| 欧美1区2区3区| 午夜视黄欧洲亚洲| 亚洲人www| 国产在线视频不卡二| 欧美日韩一区不卡| 美女视频黄免费的久久| 欧美亚洲网站| 在线亚洲欧美| 最新高清无码专区| 欧美成人三级在线| 久久精品视频在线| 亚洲一区3d动漫同人无遮挡| 亚洲大片精品永久免费| 国产一区二区电影在线观看| 国产精品高清免费在线观看| 欧美成人精品一区二区| 欧美一区二区三区四区视频| 亚洲最新中文字幕| 亚洲黑丝在线| 欧美国产一区二区三区激情无套| 久久久av网站| 久久黄色网页| 欧美一级黄色网| 校园春色国产精品|