C++箴言：多態基類中將解構函式聲明為虛擬zz

有很多方法可以跟蹤時間的軌跡，所以有必要建立一個 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

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

　　·如果不是設計用於做基類或不是設計用於多態，這樣的類就不應該聲明虛解構函式。