Shuffy

第7條：         要把多態基類的析構器聲明為虛函數

現在考慮一個計時器的問題，我們首先創建一個名為 TimeKeeper 的基類，然后在它的基礎上創建各種派生類，從而用不同手段來計時。由于計時有很多方式，所以這樣做是值得的：

許多客戶端程序員希望在訪問時間的同時，不用關心它是如何計算的，所以在此時可以使用一個工廠函數來返回一個指向計時器對象的指針，該函數返回的是一個基類指針，這個指針指向一個新創建的派生類對象：

為了不破壞工廠函數的慣例， getTimeKeeper 返回的對象被放置在堆上，所以必須要在適當的時候刪除每一個返回的對象，從而避免內存或者其他資源發生泄漏：

把釋放工作推給客戶端程序員不是一個好的做法， 第 13 條 中解釋了這一點。關于如何修改工廠函數的接口從而防止一般的客戶端錯誤發生，請參見第 18 條。但是這些議題在此都不是主要的，這一條中我們主要討論的是一個更為基本的議題，即上文中的代碼存在著更為基本的弱點：即使客戶端程序員把每一件事都做得很完美，我們仍無法預知程序會產生怎樣的行為。

現在的問題是： getTimeKeeper 返回一個指向其派生類對象的指針（比如說 AtomicClock ），這個對象通過一個基類的指針得到刪除（比如說一個 TimeKeeper* 指針），而基類（ TimeKeeper ）有一個非虛擬的析構器。這里埋藏著災難，這是因為 C++ 做出了這樣的規定：當一個派生類對象通過一個指向基類的指針來刪除，并且這一基類有一個非虛擬的析構器，此時的結果是不可預知的。通常情況下在運行時，派生類中新派生出的部分得不到銷毀。如果 getTimeKeeper 返回了一個指向 AtomicClock 對象的指針，這一對象中派生出的部分（ AtomicClock 這一部分，也就是 AtomicClock 類中新生命的數據成員）有可能不會被銷毀掉， AtomicClock 的析構器也可能不會得到運行。然而，這一對象中基類那一部分（也就是 TimeKeeper 這一部分）很自然的會被銷毀掉，這樣便會產生一個古怪的“部分被銷毀的”對象。用這種方法來泄漏資源、破壞數據結構、浪費調試時間，實在是“再好不過”了。

排除這一問題的方法很簡單：為基類提供一個虛擬的析構器。這時刪除一個派生類對象，程序就會精確地按你的需要運行了。整個對象都會得到銷毀，包括所有新派生的部分：

通常情況下，像 TimeKeeper 這樣的基類會包含除析構器以外的虛函數，這是因為虛函數的目的是允許派生類實現中對它們進行自定義（參見第 34 條）。比如說，對于 TimeKeeper 類中的 getCurrentTime 函數來說，它在不同的派生類中有可能有不同的實現方式，必須要將其聲明為虛函數。任何有虛函數的類幾乎都要包含一個虛析構器。

如果一個類不包含虛函數，通常情況下意味著它將不作為基類使用。當一個類不作為基類時，將它的析構其聲明為虛擬的通常情況下不是個好主意。請看下面的示例，這個類代表的是二維空間中的點：

在一般情況下，如果一個 int 占用 32 個位，一個 Point 對象便適合置入一個 64 位的寄存器中。而且，這樣的一個 Point 對象可以以一 個 64 位數值的形式傳給其他語言編寫的函數，比如 C 或者 FORTRAN 。然而如果 Point 的析構器是虛擬的，那么就是另一種情況了。

虛函數的實現需要它所在的對象包含額外的信息，這一信息用來在運行時確定本對象需要調用哪個虛函數。通常，這一信息采取一個指針的形式，這個指針被稱為“ vptr ”（“虛函數表指針”）。 vptr 指向一個包含函數指針的數組，這一數組稱為“ vtbl ”（“虛函數表”），每個包含虛函數的類都有一個與之相關的 vtbl 。當一個虛函數被一個對象調用時，就用到了該對象的 vptr 所指向的 vtbl ，在 vtbl 中查找一個合適的函數指針，然后調用相應的實函數。

虛函數實現的細節并不重要。重要的僅僅是，如果 Point 類包含一個虛函數，這一類型的對象將會變大。在一 個 32 位 的架構中， Point 對象將會由 64 位 （兩個 int 大小）增長至 96 位（兩個 int 加一個 vptr ）；在 64 位架構中， Point 對象將由 64 位 增長至 128 位 。這是因為指向 64 位架構的指針有 64 位 大小。可以看到，為 Point 添加一個 vptr 將會使其變 大 50-100% ！這樣，一個 64 位的 寄存器便容不下一個 Point 對象了。而且， C++ 中的 Point 對象便不再與其它語言（比 如 C 語 言）有同樣的結構，這是因為其它語言很可能沒有 vptr 的概念。于是，除非你顯式增補一個 vptr 的等價物（但這是這種語言的實現細節，而且不具備可移植性），否則 Point 對象便無法與其它語言編寫的函數互通。

不得不承認，無故將所有的析構器聲明為虛擬的，與從不將它們聲明為虛函數一樣糟糕，這一點最為重要。實際上，許多人總結出一條解決途徑：當且僅當類中至少包含一個虛函數時，要聲明一個虛析構器。

甚至在完全沒有虛函數的類里，你也可能會被非虛擬的構造器所糾纏。比如說，標準的 string 類型不包含虛函數，但是誤入歧途的程序員有些時候還是會將其作為基類：

乍一看， 這樣的代碼似乎沒什么問題，但是如果在應用時，你不知出于什么原因希望將一個指向 SpecialString 的指針轉型為指向 string 的指針，然后你又對這個 string 指針使用了 delete ，你的程序會立刻陷入無法預知的狀態：

對于所有沒有虛析構器的類上面的分析也成立，包括所有的 STL 容器類型（比如 vector 、 list 、 set 、 tr1::unordered_map （參見第 54 條），等等）。如果你曾經繼承過一個標準容器或者其他任何包含非虛析構器的類，一定要打消這個念頭！（遺憾的是， C++ 沒有提供類似 Java 中的 final 類或 C# 中的 sealed 類那種防止繼承的機制）

在個別情況下，為一個類提供一個純虛析構器是十分方便的。你可以回憶一下，純虛函數將會使所在的類變成抽象類——這種類不可以實例化（也就是說，你無法創建這種類型的對象）。然而某些時刻，你希望一個類成為一個抽象類，但是你有沒有任何純虛函數，這時候要怎么辦呢？因為抽象類應該作為基類來使用，而基類應該有虛析構器，又因為純虛函數可以造就一個抽象類，那么解決方案就顯而易見了：如果你希望一個類成為一個抽象類，那么在其中聲明一個純虛析構器。下邊是示例：

這個類有一個純虛析函數，所以它是一個抽象類，同時它擁有一個虛析構器，所以你不需要擔心析構器出現問題。然而這里還是有一個別扭的地方：你必須為純虛析構器提供一個定義：

析構器的工作方式是這樣的：首先調用最后派生出的類的析構器，然后依次調用上一層基類的析構器。由于當調用一個 AWOV 的派生類的析構器時，編譯器會自動調用 ~AWOV ，因此你必須為 ~AWOV 提供一個函數體。否則連接器將會報錯。

為基類提供虛析構器的原則僅對多態基類（這種基類允許通過其接口來操控派生類的類型）有效。我們說 TimeKeeper 是一個多態基類，這是由于即使我們手頭只有 TimeKeeper 指向它們的指針，我們仍可以對 AtomicClock 和 WaterClock 進行操控。

并不是所有的基類都要具有多態性。比如說，標準 string 類型、 STL 容器都不用作基類，因此它們都不具備多態性。另外有一些類是設計用作基類的，但是它們并未被設計成多態類。這些類（例如 第 6 條 中的 Uncopyable 和標準類中的 input_iterator_tag （參見第 47 條 ））不允許通過其接口來操控它的派生類。因此，它們并不需要虛析構器。

需要記住的

l 應該為多態基類聲明虛析構器。一旦一個類包含虛函數，它就應該包含一個虛析構器。

l 如果一個類不用作基類或者不需具有多態性，便不應該為它聲明虛析構器。