[轉]http://m.shnenglu.com/tiandejian/archive/2007/04/27/ecpp_09.html
第9條：永遠 不要在構造或析構的過程中調用虛函數

讓我們直切正題：在程序進行構造或析構期間，你絕不能調用虛函數，這是因為這樣的調用并不會按你所期望的執行，即使能夠順利執行，你也不會覺得十分 舒服。如果你曾經是一個 Java 或 C# 的程序員，并且在最近期望返回 C++ 的懷抱，那么請你格外的注意這一條，因為在這一問題上， C++ 與其他語言走的是完全不同的兩條路線。

假設有一個股票交易模擬系統，你為它編寫了一個類的層次化結構，其中包括實現購買、拋售等功能的類。會計應該能夠對這類交易進行檢查，這一點很重要，所以說每創建一次交易時，都應該在日志中進行一次恰當的記錄。下面是一個看似合理的解決方案：

請考慮一下當下邊的代碼得到運行時會發生什么：

很明顯的是此時 BuyTransaction 的構造函數將被調用，但是，首先必須調用一個 Transaction[1] 的構造函數。對于一個派生的對象，其基類那一部分會首先得到構造，然后才是派生類的部分。 Transaction 的構造函數中最后一行調用了虛函數 logTransaction ，意外的事情就從這里發生了：此處調用的是 Translation 版本的 logTransaction 函數，而不是 BuyTransaction 版本的——即使此處創建的對象是 BuyTransaction 類型的。在基類得到構造的時候，虛函數永遠也不會嘗試去匹配派生類。取而代之的是，對象仍然保持基類的行為。更隨意一點的說法是，在基類得到構造的過程中，虛函數并不會轉換為派生類的版本。

這一行為看上去匪夷所思，但是這里有很充足的理由來解釋它。由于基類的構造函數先于派生類運行，在基類構造函數得到運行的時候，派生類的數據成員還沒有被初始化。如果虛函數在基類構造函數向下匹配派生類時得到了調用，那么基類函數幾乎都將與局部數據成員有關，但此時這些數據成員仍未得到初始化。你的程序將會出現無盡的不可預知的行為，你也會在整夜受到瑣碎的調試工作的折磨。當一個對象中有一些部分還沒有得到初始化的時候，此時進行調用固然是危險的，所以 C++ 不允許你這樣做。

實際上，本段介紹的內容比上文更為基礎。對于一個派生類的對象來說，在其基類的構造函數得到運行的時候，這一對象的類型就是基類的。不僅僅虛函數會解析為基類的，而且 C++ 中使用運行時類型信息 的部分（比如 dynamic_cast （參見第 27 條）和 typeid ）也會將這個對象的類型看作基類的。在我們的示例中，為了初始化 BuyTransaction 對象中的基類部分，需要調用 Transaction 的構造函數，此時這一對象是 Transaction 類型的。以上介紹的就是 C++ 如何一一處理該對象的 每一部分，這種處理方式是有意義的：這個對象的 BuyTransaction 部分尚未得到初始化，所以認為它們不存在是最安全的處理方法。直到派生類的構造函數開始執行，這個派生類產生的對象才會成為該派生類的對象。

對于析構過程可以應用同樣的推理方式。當一個派生類的析構函數開始運行時，對象中派生類的那一部分數據成員將可能出現未知的行為，所以 C++ 會認為它們并不存在。當基類的析構函數被調用時，這個對象將成為一個基類對象， C++ 所 有的部分——包括虛函數、 dynamic_cast 等等——都會這樣對待該對象。

在上文的示例代碼中， Transaction 的構造函數對一個虛函數進行了一次直接調用，很顯然這樣做是違背本條中的指導方針的。這樣的違規實在太容易發現了，一些編譯器都會對其做出警告。（其他一些則不會。參見 第 53 條對編譯器警告信息的討論 ）即使沒有警告，問題依舊一定會在運行之前變得很明顯，這是因為 Transaction 中的 logTransaction 函數是純虛函數，除非它得到了定義（不像是真的，但確實是可行的，參見第 34 條 ），程序才有可能會得到連接，其他情況都會報錯：連接器無法找到 Transaction::logTransaction 所必需的具體實現。

查找構造和析構過程中對虛函數的調用并不總是一帆風順的。如果 Transaction 擁有多個構造函數，它們所進行的工作中有一部分是相同的，那么可以將這一相同的部分（既公共初始化代碼）連同對 logTransaction 的調用放入一個私有的非虛初始化函數中，這樣做可以避免代碼重復，從軟件工程角度來講這似乎是一個很好的做法，我們將這一函數命名為 init ：

這樣的代碼與上文中的版本使用的是同一理念，但是這樣做所帶來的危害更為隱蔽和嚴重，這是因為這樣的代碼會得到正常的編譯和連接而不會報錯。這種情況下，由于 logTransaction 是一個 Transaction 中的純虛函數，大多數運行時系統將會在調用這個純虛函數時終止程序的運行（通常情況下會針對這一結果顯示出一個消息）。然而如果 logTransaction 是一個“正常的”虛函數（也就是說，不是純虛的），并且在 Transaction 中給出了一些實現，這一版本將能夠得到調用，程序將會“愉快地一路小跑”下去，而在創建一個派生類對象時，則會調用錯誤的 logTransaction 版本，為什么會這樣呢？這個問題只能由你自己來解決了。避免這類問題的唯一途徑就是：在正在創建或銷毀的對象的構造函數和析構函數中，確保永遠不要調用虛函數，對于構造函數和析構函數所調用的所有函數都應遵守這一約定。

那么，每當一個 Transaction 層的對象被創建時，如何確保去調用正確的 logTransaction 版本呢？顯然地，在 Transaction 的構造函數中調用一個虛函數是一個錯誤的做法。

為解決這一問題我們可以另辟蹊徑。方案之一就是：將 Transaction 中的 logTransaction 變為一個非虛函數，然后要求派生類的構造函數把必要的日志記錄傳遞給 Transaction 的構造函數。這個構造函數對于非虛 logTransaction 的調用就是安全的。就像這樣：

換句話說，由于在構造過程中，你不能在基類部分調用派生部分時使用虛函數，此時，作為一種補償，你可以讓派生類為基類的構造函數傳遞一些必要的構造信息。

請注意上述示例里 BuyTransaction 類中靜態函數 createLogString 的使用。這里使用了一個輔助函數來創建一個值，然后將這個值傳遞給基類構造函數，通常情況下這樣做更為方便（而且更具備可讀性），這樣做不會出現在成員初始化表中為基類提供所需信息所帶來的曲折性。由于這個函數被聲明為靜態的，將不會出現偶然觸及到這個初生的 BuyTransaction 對象中的那些看似未初始化的數據成員的危險。這一點很重要，因為這些數據成員正處于一個未知的狀態，這一事實便解釋了為什么在基類部分構造或析構期間調用虛函數將不會在第一時間匹配到派生類。

需要記住的

l 不要在構造和析構的過程中調用虛函數，因為這樣的調用永遠不會轉向當前執行的析構函數或構造函數更深層的派生類中執行。