• <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>

            大龍的博客

            常用鏈接

            統(tǒng)計(jì)

            最新評(píng)論

            確定基類有虛析構(gòu)函數(shù)

            ?
            ?

            條款14: 確定基類有虛析構(gòu)函數(shù)

            有時(shí),一個(gè)類想跟蹤它有多少個(gè)對(duì)象存在。一個(gè)簡單的方法是創(chuàng)建一個(gè)靜態(tài)類成員來統(tǒng)計(jì)對(duì)象的個(gè)數(shù)。這個(gè)成員被初始化為0,在構(gòu)造函數(shù)里加1,析構(gòu)函數(shù)里減1。(條款m26里說明了如何把這種方法封裝起來以便很容易地添加到任何類中,“my article on counting objects”提供了對(duì)這個(gè)技術(shù)的另外一些改進(jìn))

            設(shè)想在一個(gè)軍事應(yīng)用程序里,有一個(gè)表示敵人目標(biāo)的類:

            class enemytarget {
            public:
            ? enemytarget() { ++numtargets; }
            ? enemytarget(const enemytarget&) { ++numtargets; }
            ? ~enemytarget() { --numtargets; }

            ? static size_t numberoftargets()
            ? { return numtargets; }

            ? virtual bool destroy();?????? // 摧毀enemytarget對(duì)象后
            ??????????????????????????????? // 返回成功

            private:
            ? static size_t numtargets;???? // 對(duì)象計(jì)數(shù)器
            };

            // 類的靜態(tài)成員要在類外定義;
            // 缺省初始化為0
            size_t enemytarget::numtargets;

            這個(gè)類不會(huì)為你贏得一份政府防御合同,它離國防部的要求相差太遠(yuǎn)了,但它足以滿足我們這兒說明問題的需要。

            敵人的坦克是一種特殊的敵人目標(biāo),所以會(huì)很自然地想到將它抽象為一個(gè)以公有繼承方式從enemytarget派生出來的類(參見條款35及m33)。因?yàn)椴坏P(guān)心敵人目標(biāo)的總數(shù),也要關(guān)心敵人坦克的總數(shù),所以和基類一樣,在派生類里也采用了上面提到的同樣的技巧:

            class enemytank: public enemytarget {
            public:
            ? enemytank() { ++numtanks; }

            ? enemytank(const enemytank& rhs)
            ? : enemytarget(rhs)
            ? { ++numtanks; }

            ? ~enemytank() { --numtanks; }

            ? static size_t numberoftanks()
            ? { return numtanks; }

            ? virtual bool destroy();

            private:
            ? static size_t numtanks;???????? // 坦克對(duì)象計(jì)數(shù)器
            };

            (寫完以上兩個(gè)類的代碼后,你就更能夠理解條款m26對(duì)這個(gè)問題的通用解決方案了。)

            最后,假設(shè)程序的其他某處用new動(dòng)態(tài)創(chuàng)建了一個(gè)enemytank對(duì)象,然后用delete刪除掉:

            enemytarget *targetptr = new enemytank;

            ...

            delete targetptr;

            到此為止所做的一切好象都很正常:兩個(gè)類在析構(gòu)函數(shù)里都對(duì)構(gòu)造函數(shù)所做的操作進(jìn)行了清除;應(yīng)用程序也顯然沒有錯(cuò)誤,用new生成的對(duì)象在最后也用delete刪除了。然而這里卻有很大的問題。程序的行為是不可預(yù)測的——無法知道將會(huì)發(fā)生什么。

            c++語言標(biāo)準(zhǔn)關(guān)于這個(gè)問題的闡述非常清楚:當(dāng)通過基類的指針去刪除派生類的對(duì)象,而基類又沒有虛析構(gòu)函數(shù)時(shí),結(jié)果將是不可確定的。這意味著編譯器生成的代碼將會(huì)做任何它喜歡的事:重新格式化你的硬盤,給你的老板發(fā)電子郵件,把你的程序源代碼傳真給你的對(duì)手,無論什么事都可能發(fā)生。(實(shí)際運(yùn)行時(shí)經(jīng)常發(fā)生的是,派生類的析構(gòu)函數(shù)永遠(yuǎn)不會(huì)被調(diào)用。在本例中,這意味著當(dāng)targetptr 刪除時(shí),enemytank的數(shù)量值不會(huì)改變,那么,敵人坦克的數(shù)量就是錯(cuò)的,這對(duì)需要高度依賴精確信息的部隊(duì)來說,會(huì)造成什么后果?)

            為了避免這個(gè)問題,只需要使enemytarget的析構(gòu)函數(shù)為virtual。聲明析構(gòu)函數(shù)為虛就會(huì)帶來你所希望的運(yùn)行良好的行為:對(duì)象內(nèi)存釋放時(shí),enemytank和enemytarget的析構(gòu)函數(shù)都會(huì)被調(diào)用。

            和絕大部分基類一樣,現(xiàn)在enemytarget類包含一個(gè)虛函數(shù)。虛函數(shù)的目的是讓派生類去定制自己的行為(見條款36),所以幾乎所有的基類都包含虛函數(shù)。

            如果某個(gè)類不包含虛函數(shù),那一般是表示它將不作為一個(gè)基類來使用。當(dāng)一個(gè)類不準(zhǔn)備作為基類使用時(shí),使析構(gòu)函數(shù)為虛一般是個(gè)壞主意。請(qǐng)看下面的例子,這個(gè)例子基于arm(“the annotated c++ reference manual”)一書的一個(gè)專題討論。

            // 一個(gè)表示2d點(diǎn)的類
            class point {
            public:
            ? point(short int xcoord, short int ycoord);
            ? ~point();

            private:
            ? short int x, y;
            };

            如果一個(gè)short int占16位,一個(gè)point對(duì)象將剛好適合放進(jìn)一個(gè)32位的寄存器中。另外,一個(gè)point對(duì)象可以作為一個(gè)32位的數(shù)據(jù)傳給用c或fortran等其他語言寫的函數(shù)中。但如果point的析構(gòu)函數(shù)為虛,情況就會(huì)改變。

            實(shí)現(xiàn)虛函數(shù)需要對(duì)象附帶一些額外信息,以使對(duì)象在運(yùn)行時(shí)可以確定該調(diào)用哪個(gè)虛函數(shù)。對(duì)大多數(shù)編譯器來說,這個(gè)額外信息的具體形式是一個(gè)稱為vptr(虛函數(shù)表指針)的指針。vptr指向的是一個(gè)稱為vtbl(虛函數(shù)表)的函數(shù)指針數(shù)組。每個(gè)有虛函數(shù)的類都附帶有一個(gè)vtbl。當(dāng)對(duì)一個(gè)對(duì)象的某個(gè)虛函數(shù)進(jìn)行請(qǐng)求調(diào)用時(shí),實(shí)際被調(diào)用的函數(shù)是根據(jù)指向vtbl的vptr在vtbl里找到相應(yīng)的函數(shù)指針來確定的。

            虛函數(shù)實(shí)現(xiàn)的細(xì)節(jié)不重要(當(dāng)然,如果你感興趣,可以閱讀條款m24),重要的是,如果point類包含一個(gè)虛函數(shù),它的對(duì)象的體積將不知不覺地翻番,從2個(gè)16位的short變成了2個(gè)16位的short加上一個(gè)32位的vptr!point對(duì)象再也不能放到一個(gè)32位寄存器中去了。而且,c++中的point對(duì)象看起來再也不具有和其他語言如c中聲明的那樣相同的結(jié)構(gòu)了,因?yàn)檫@些語言里沒有vptr。所以,用其他語言寫的函數(shù)來傳遞point也不再可能了,除非專門去為它們?cè)O(shè)計(jì)vptr,而這本身是實(shí)現(xiàn)的細(xì)節(jié),會(huì)導(dǎo)致代碼無法移植。

            所以基本的一條是,無故的聲明虛析構(gòu)函數(shù)和永遠(yuǎn)不去聲明一樣是錯(cuò)誤的。實(shí)際上,很多人這樣總結(jié):當(dāng)且僅當(dāng)類里包含至少一個(gè)虛函數(shù)的時(shí)候才去聲明虛析構(gòu)函數(shù)。

            這是一個(gè)很好的準(zhǔn)則,大多數(shù)情況都適用。但不幸的是,當(dāng)類里沒有虛函數(shù)的時(shí)候,也會(huì)帶來非虛析構(gòu)函數(shù)問題。 例如,條款13里有個(gè)實(shí)現(xiàn)用戶自定義數(shù)組下標(biāo)上下限的類模板。假設(shè)你(不顧條款m33的建議)決定寫一個(gè)派生類模板來表示某種可以命名的數(shù)組(即每個(gè)數(shù)組有一個(gè)名字)。

            template<class t>??????????????? // 基類模板
            class array {??????????????????? // (來自條款13)
            public:
            ? array(int lowbound, int highbound);
            ? ~array();

            private:
            ? vector<t> data;
            ? size_t size;
            ? int lbound, hbound;
            };

            template<class t>
            class namedarray: public array<t> {
            public:
            ? namedarray(int lowbound, int highbound, const string& name);
            ? ...

            private:
            ? string arrayname;
            };

            如果在應(yīng)用程序的某個(gè)地方你將指向namedarray類型的指針轉(zhuǎn)換成了array類型的指針,然后用delete來刪除array指針,那你就會(huì)立即掉進(jìn)“不確定行為”的陷阱中。

            namedarray<int> *pna =
            ? new namedarray<int>(10, 20, "impending doom");

            array<int> *pa;

            ...


            pa = pna;??????????????? // namedarray<int>* -> array<int>*

            ...

            delete pa;?????????????? // 不確定! 實(shí)際中,pa->arrayname
            ???????????????????????? // 會(huì)造成泄漏,因?yàn)?pa的namedarray
            ???????????????????????? // 永遠(yuǎn)不會(huì)被刪除


            現(xiàn)實(shí)中,這種情形出現(xiàn)得比你想象的要頻繁。讓一個(gè)現(xiàn)有的類做些什么事,然后從它派生一個(gè)類做和它相同的事,再加上一些特殊的功能,這在現(xiàn)實(shí)中不是不常見。namedarray沒有重定義array的任何行為——它繼承了array的所有功能而沒有進(jìn)行任何修改——它只是增加了一些額外的功能。但非虛析構(gòu)函數(shù)的問題依然存在(還有其他問題,參見m33)

            最后,值得指出的是,在某些類里聲明純虛析構(gòu)函數(shù)很方便。純虛函數(shù)將產(chǎn)生抽象類——不能實(shí)例化的類(即不能創(chuàng)建此類型的對(duì)象)。有些時(shí)候,你想使一個(gè)類成為抽象類,但剛好又沒有任何純虛函數(shù)。怎么辦?因?yàn)槌橄箢愂菧?zhǔn)備被用做基類的,基類必須要有一個(gè)虛析構(gòu)函數(shù),純虛函數(shù)會(huì)產(chǎn)生抽象類,所以方法很簡單:在想要成為抽象類的類里聲明一個(gè)純虛析構(gòu)函數(shù)。

            這里是一個(gè)例子:

            class awov {??????????????? // awov = "abstract w/o
            ??????????????????????????? // virtuals"
            public:
            ? virtual ~awov() = 0;????? // 聲明一個(gè)純虛析構(gòu)函數(shù)
            ???????????????????????????
            };

            這個(gè)類有一個(gè)純虛函數(shù),所以它是抽象的,而且它有一個(gè)虛析構(gòu)函數(shù),所以不會(huì)產(chǎn)生析構(gòu)函數(shù)問題。但這里還有一件事:必須提供純虛析構(gòu)函數(shù)的定義:

            awov::~awov() {}?????????? // 純虛析構(gòu)函數(shù)的定義

            這個(gè)定義是必需的,因?yàn)樘撐鰳?gòu)函數(shù)工作的方式是:最底層的派生類的析構(gòu)函數(shù)最先被調(diào)用,然后各個(gè)基類的析構(gòu)函數(shù)被調(diào)用。這就是說,即使是抽象類,編譯器也要產(chǎn)生對(duì)~awov的調(diào)用,所以要保證為它提供函數(shù)體。如果不這么做,鏈接器就會(huì)檢測出來,最后還是得回去把它添上。

            可以在函數(shù)里做任何事,但正如上面的例子一樣,什么事都不做也不是不常見。如果是這種情況,那很自然地會(huì)想到將析構(gòu)函數(shù)聲明為內(nèi)聯(lián)函數(shù),從而避免對(duì)一個(gè)空函數(shù)的調(diào)用所產(chǎn)生的開銷。這是一個(gè)很好的方法,但有一件事要清楚。

            因?yàn)槲鰳?gòu)函數(shù)為虛,它的地址必須進(jìn)入到類的vtbl(見條款m24)。但內(nèi)聯(lián)函數(shù)不是作為獨(dú)立的函數(shù)存在的(這就是“內(nèi)聯(lián)”的意思),所以必須用特殊的方法得到它們的地址。條款33對(duì)此做了全面的介紹,其基本點(diǎn)是:如果聲明虛析構(gòu)函數(shù)為inline,將會(huì)避免調(diào)用它們時(shí)產(chǎn)生的開銷,但編譯器還是必然會(huì)在什么地方產(chǎn)生一個(gè)此函數(shù)的拷貝。

            本文來源:http://www.leftworld.net/online/effectivec/file/ch04a.htm

            posted on 2006-09-24 16:58 大龍 閱讀(245) 評(píng)論(0)  編輯 收藏 引用


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久线看观看精品香蕉国产| 人妻无码精品久久亚瑟影视| 2021国产成人精品久久| 久久97久久97精品免视看| 亚洲精品第一综合99久久| 国产精品青草久久久久婷婷| 久久伊人亚洲AV无码网站| 久久精品国产清高在天天线| 久久伊人影视| 99国产精品久久| 久久久久亚洲精品日久生情| 国产毛片久久久久久国产毛片 | 精品久久人人爽天天玩人人妻| 欧美一区二区三区久久综| 久久99精品免费一区二区| 亚洲精品国精品久久99热一| 无码人妻少妇久久中文字幕 | 久久国产精品久久久| 中文字幕人妻色偷偷久久| 日韩欧美亚洲国产精品字幕久久久 | 久久无码av三级| 国产亚洲综合久久系列| 久久久www免费人成精品| 欧美精品福利视频一区二区三区久久久精品 | 亚洲国产精品18久久久久久| 亚洲国产高清精品线久久| 曰曰摸天天摸人人看久久久| 国产高潮国产高潮久久久| 久久久久久亚洲Av无码精品专口 | 91久久精品国产成人久久| 国产精品一久久香蕉产线看 | 国产韩国精品一区二区三区久久| 亚洲中文字幕久久精品无码喷水| 久久国内免费视频| 怡红院日本一道日本久久 | 国产亚洲精品久久久久秋霞 | 亚洲女久久久噜噜噜熟女| 亚洲精品美女久久777777| 精品人妻久久久久久888| 2022年国产精品久久久久| 欧美久久综合性欧美|