GotW #22 Object Lifetimes – Part I<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

著者：Herb Sutter

翻譯：K ][ N G of @rk™

[宣告]：本文內容取自www.gotw.ca網站上的Guru of the Week欄目，其著作權歸原著者本人所有。譯者kingofark在未經原著者本人同意的情況下翻譯本文。本翻譯內容僅供自學和參考用，請所有閱讀過本文的人不要擅自轉載、傳播本翻譯內容；下載本翻譯內容的人請在閱讀瀏覽後，立即刪除其備份。譯者

Revision 1.0

Guru of the Week條款22：物件的生存期（第一部分）

難度：5 / 10

（“生存，還是滅亡……[譯註：這是莎士比亞所著《哈姆雷特》中的名句]” 一個物件何時才算是真實存在的？這個問題用來考察一個物件何時才能被安全的使用。）

[Problem]

[問題]

評述下面的程式段。#2處的程式碼使安全和/或合法的嗎？請對你的回答做出解釋。

[解答]

是的，#2處的程式碼是安全且合法的（如果只考慮這部分程式碼的話），但：

a)函式作為一個整體，它是不安全的，而且

b)這樣做是一個壞習慣。

[

C++標準草案明確規定，允許這種程式碼出現。現場的析構和重構造（in-place destruction and reconstruction）不會使rt這個引用失效。（當然，你不能在t.~T()與placement new之間使用t或rt，因為在那段時期裡不存在任何物件。我們還假設T::operator&()沒有被過載，即沒有被用來做「返回物件之地址」以外的其它事情。）

我們之所以說“如果只考慮這部分程式碼的話，#2就是安全的”，是因為f()作為一個整體而言，可能不是異常安全的（exception-safe）：

[為什麼函式是不安全的？

如果在呼叫T(2)的時候，T的建構函式有丟擲異常的可能，那麼f()就不是異常安全的。考慮其原因：如果T(2)丟擲異常，那麼在原來’t’所在的記憶體區域中將不會有新的物件被構造，而在函式末尾T::~T()仍然被正常呼叫（因為t是一個自動變數[automatic variable]），而且正如程式碼中的註釋所述，“t被再次銷燬”。這即是說，’t’會被構造一次，卻被銷燬兩次（嗚呼呀）。這將導致容易產生無法預見的副作用，比如core dumps。

[為什麼這是個壞習慣？]

如果忽略異常安全性的問題，那麼程式碼在這樣的設定下恰好就能夠正常工作，這是因為程式設計師此時知道被構造和銷燬之物件的具體型別。這即是說，該物件是一個T，並被作為一個T來被銷燬和重新構造。

在實際的程式碼中，這種技術（即便真是編碼所需）幾乎不會被使用，並且這樣做也是非常壞的習慣；原因是：如果其出現在成員函式中，那麼其將會充滿（有時難以捉摸的）危險：

現在這種技術還算安全嗎？基本上來說，不安全。考慮下面的程式碼：

如果”/*AAA*/”是”T”，那麼#2處的程式碼仍然可行，即使”/*BBB*/”不是”T”（ ”/*BBB*/”可能是T的基類）。

如果”/*AAA*/”是”U”（譯註：而不是”T”），那麼無論”/*BBB*/”是什麼，都已經毫無懸念了。大概你所能期待的最好結果就是一個及時的core dump，因為對t.f()的呼叫將物件“切割（slices）”了。這裡說的“切割”是指：t.f()用屬於另一個不同型別的物件替換了原來的物件——這即是說函式使用了T而不是U。即便是你意欲編寫不可移植的程式碼，你也無法知曉「當原來U所在的記憶體區域被T物件之資料抹蓋以後，其被作為U是否還可用？」。固然還是有情況尚佳的機率，但是請不要走到那個地步……這絕不是一次良好的實踐。

本期GotW包含了一些基本的、有關現場析構和重構（in-place destruction and reconstruction）的安全性問題和切割問題。這為下期的“GotW條款23：物件生存期（第二部分）”作下鋪墊。

（完）