C++箴言：多態基類中將析構函數聲明為虛擬

2019-11-17 05:12:07

字體：大中小

來源：轉載

供稿：網友

　　有很多方法可以跟蹤時間的軌跡，所以有必要建立一個 TimeKeeper 基類，并為不同的計時方法建立派生類：

class TimeKeeper {
　public:
　　TimeKeeper();
　　~TimeKeeper();
　...
};

class AtomicClock: public TimeKeeper { ... };
class WaterClock: public TimeKeeper { ... };
class WristWatch: public TimeKeeper { ... };
　　很多客戶只是想簡單地取得時間而不關心如何計算的細節，所以一個 factory 函數——返回一個指向新建派生類對象的基類指針的函數——被用來返回一個指向計時對象的指針：

TimeKeeper* getTimeKeeper(); // returns a pointer to a dynamic-
// ally allocated object of a class
// derived from TimeKeeper
　　按照 factory 函數的慣例，getTimeKeeper 返回的對象是建立在堆上的，所以為了避免泄漏內存和其他資源，最重要的就是要讓每一個返回的對象都可以被完全刪除。

TimeKeeper *ptk = getTimeKeeper(); // get dynamically allocated object
// from TimeKeeper hierarchy

... // use it

delete ptk; // release it to avoid resource leak
　　現在我們精力集中于上面的代碼中一個更基本的缺陷：即使客戶做對了每一件事，也無法預知程序將如何運轉。

　　問題在于 getTimeKeeper 返回一個指向派生類對象的指針（比如 AtomicClock），那個對象通過一個基類指針（也就是一個 TimeKeeper* 指針）被刪除，而且這個基類（TimeKeeper）有一個非虛的析構函數。禍端就在這里，因為 C++ 指出：當一個派生類對象通過使用一個基類指針刪除，而這個基類有一個非虛的析構函數，則結果是未定義的。運行時比較有代表性的后果是對象的派生部分不會被銷毀。假如 getTimeKeeper 返回一個指向 AtomicClock 對象的指針，則對象的 AtomicClock 部分（也就是在 AtomicClock 類中聲明的數據成員）很可能不會被銷毀，AtomicClock 的析構函數也不會運行。然而，基類部分（也就是 TimeKeeper 部分）很可能已被銷毀，這就導致了一個古怪的“部分析構”對象。這是一個泄漏資源，破壞數據結構以及消耗大量調試時間的絕妙方法。排除這個問題非常簡單：給基類一個虛析構函數。于是，刪除一個派生類對象的時候就有了你所期望的正確行為。將銷毀整個對象，包括全部的派生類部分：

class TimeKeeper {
　public:
　　TimeKeeper();
　　virtual ~TimeKeeper();
　　...
};

TimeKeeper *ptk = getTimeKeeper();
...
delete ptk; // now behaves correctly
　　類似 TimeKeeper 的基類一般都包含除了析構函數以外的其它虛函數，因為虛函數的目的就是答應派生類定制實現（參見 Item 34）。例如，TimeKeeper 可能有一個虛函數 getCurrentTime，在各種不同的派生類中有不同的實現。幾乎所有擁有虛函數的類差不多都應該有虛析構函數。

　　假如一個類不包含虛函數，這經常預示不打算將它作為基類使用。當一個類不打算作為基類時，將析構函數聲明為虛擬通常是個壞主意。考慮一個表現二維空間中的點的類：

class Point { // a 2D point
　public:
　　Point(int xCoord, int yCoord);
　　~Point();
　PRivate:
　　int x, y;
};
　　假如一個 int 占 32 位，一個 Point 對象正好適用于 64 位的寄存器。而且，這樣一個 Point 對象可以被作為一個 64 位的量傳遞給其它語言寫的函數，比如 C 或者 FORTRAN。假如 Point 的析構函數是虛擬的，情況就完全不一樣了。

　　虛函數的實現要求對象攜帶額外的信息，這些信息用于在運行時確定該對象應該調用哪一個虛函數。典型情況下，這一信息具有一種被稱為 vptr（virtual table pointer，虛函數表指針）的指針的形式。vptr 指向一個被稱為 vtbl（virtual table，虛函數表）的函數指針數組，每一個包含虛函數的類都關聯到 vtbl。當一個對象調用了虛函數，實際的被調用函數通過下面的步驟確定：找到對象的 vptr 指向的 vtbl，然后在 vtbl 中尋找合適的函數指針。

　　虛函數如何被實現的細節是不重要的。重要的是假如 Point 類包含一個虛函數，這個類型的對象的大小就會增加。在一個 32 位架構中，它們將從 64 位（相當于兩個 int）長到 96 位（兩個 int 加上 vptr）；在一個 64 位架構中，他們可能從 64 位長到 128 位，因為在這樣的架構中指針的大小是 64 位的。為 Point 加上 vptr 將會使它的大小增長 50-100%！Point 對象不再適合 64 位寄存器。而且，Point 對象在 C++ 和其他語言（比如 C）中，看起來不再具有相同的結構，因為其它語言缺乏 vptr 的對應物。結果，Points 不再可能傳入其它語言寫成的函數或從其中傳出，除非你為 vptr 做出明確的對應，而這是它自己的實現細節并因此失去可移植性。

　　這里的基準就是不加選擇地將所有析構函數聲明為虛擬，和從不把它們聲明為虛擬一樣是錯誤的。實際上，很多人總結過這條規則：當且僅當類中至少包含一個虛擬函數時，則聲明一個虛析構函數。

　　但是，當完全沒有虛函數時，就可能和非虛析構函數問題發生撕咬。例如，標準 string 類型不包含虛函數，但是被誤導的程序員有時將它當作基類使用：

class SpecialString: public std::string { // bad idea! std::string has a
... // non-virtual destrUCtor
};
　　一眼看上去，這可能無傷大雅，但是，假如在程序的某個地方因為某種原因，你將一個指向 SpecialString 的指針轉型為一個指向 string 的指針，然后你將 delete 施加于這個 string 指針，你就馬上被送入未定義行為的領地。

SpecialString *pss = new SpecialString("Impending Doom");

std::string *ps;
...
ps = pss; // SpecialString* => std::string*
...
delete ps; // undefined! In practice,
// *ps’s SpecialString resources
// will be leaked, because the
// SpecialString destructor won’t
// be called.
　　同樣的分析可以適用于任何缺少虛析構函數的類，包括全部的 STL 容器類型（例如，vector，list，set，tr1::unordered_map。假如你受到從標準容器類或任何其他帶有非虛析構函數的類派生的誘惑，一定要挺住！（不幸的是，C++ 不提供類似 java 的 final 類或 C# 的 sealed 類的防派生氣制。）偶然地，給一個類提供一個純虛析構函數能提供一些便利。回想一下，純虛函數導致抽象類——不能被實例化的類（也就是說你不能創建這個類型的對象）。有時候，你有一個類，你希望它是抽象的，但沒有任何純虛函數。怎么辦呢？因為一個抽象類注定要被用作基類，又因為一個基類應該有一個虛析構函數，又因為一個純虛函數產生一個抽象類，好了，解決方案很簡單：在你希望成為抽象類的類中聲明一個純虛析構函數。這是一個例子：

class AWOV { // AWOV = "Abstract w/o Virtuals"
public:
　virtual ~AWOV() = 0; // declare pure virtual destructor
};
　　這個類有一個純虛函數，所以它是抽象的，又因為它有一個虛析構函數，所以你不必擔心析構函數問題。這是一個螺旋。你必須為純虛析構函數提供一個定義：

AWOV::~AWOV() {} // definition of pure virtual dtor
　　析構函數的工作方式是：最底層的派生類（most derived class）的析構函數最先被調用，然后調用每一個基類的析構函數。編譯器會產生一個從派生類的析構函數對 ~AWOV 的調用，所以你不得不確實為函數提供一個函數體。假如你不這樣做，連接程序會提出抗議。

　　為基類提供虛析構函數的規則僅僅適用于多態基類——基類被設計用來答應派生類型通過基類的接口進行操作。TimeKeeper 就是一個多態基類，因為我們期望能操作 AtomicClock 和 WaterClock 對象，甚至當我們僅有指向他們的類型為 TimeKeeper 的指針的時候。

　　并非所有的基類都被設計用于多態。例如，無論是標準 string 類型，還是 STL 容器類型都被完全設計成基類，可沒有哪個是多態的。一些類雖然被設計用于基類，但并非被設計用于多態。這樣的類——例如Uncopyable 和標準庫中的 input_iterator_tag——沒有被設計成答應通過基類的接口操作派生類對象。所以它們就不需要虛析構函數。

　　Things to Remember

　　·多態基類應該聲明虛析構函數。假如一個類有任何虛函數，它就應該有一個虛析構函數。

　　·假如不是設計用于做基類或不是設計用于多態，這樣的類就不應該聲明虛析構函數。