Shuffy

[轉(zhuǎn)]http://m.shnenglu.com/tiandejian/archive/2007/04/15/ecpp_04.html

第1項(xiàng)：    確保對象在使用前得到初始化

C++ 在對象初始值問題上顯得變化多端。比如說，你寫下了下面的代碼：

在許多情況下， x 會確保得到初始化（為零），但是另一些情況下則不會，如果你這樣編寫：

p 的數(shù)據(jù)成員在一些情況下會確保得到初始化（為零），但是另一些情況就不會了。如果你以前學(xué)習(xí)的語言沒有對象初始化的概念，那么請你注意了，因?yàn)檫@很重要。

讀取未初始化的數(shù)據(jù)時，程序?qū)⒊尸F(xiàn)出無法預(yù)知的行為。在一些語言平臺中，通常情況下讀取未初始化的數(shù)據(jù)將使你的程序無法運(yùn)行。更可能的情況時，也許會得到內(nèi)存中某些位置上的半隨機(jī)的數(shù)據(jù)，這些數(shù)據(jù)將會“污染”需要賦值的對象，最終，程序的行為將變得十分令人費(fèi)解，你也會陷入令人惱火的除錯工作。

現(xiàn)在，人們制定了規(guī)則來規(guī)定：對象在什么時候確保會得到初始化，以及什么時候不會。但是遺憾的是，這些規(guī)則太過復(fù)雜了——在我看來，你根本沒必要去記憶它們。整體上講，如果你正在使用 C++ 中 C 語言的一部分（參見第 1 項(xiàng)），那么初始化會引入一些額外的運(yùn)行時開銷，這一部分中對象不會確保初始化。但當(dāng)你使用 非 C 的 C++ 部 分時，情況就有所改變。這便可以解釋為什么數(shù)組（ C++ 中的 C 語言）不會確保得到初始化，而一個 vector （ C++ 中的 STL ）會。

解決這類表面上的不確定性問題最好的途徑就是：總是在使用對象之前對它們進(jìn)行初始化。對于內(nèi)建類型的非成員對象，你需要手動完成這一工作。請看下邊的示例：

對于其他大多數(shù)情況而言，初始化的重?fù)?dān)就落在了構(gòu)造器的肩上。這里的規(guī)則很簡單：確保所有的構(gòu)造器初始化了對象中的所有東西。

遵守這一規(guī)則是件很容易的事情，但是還有件重要的事：不要把賦值和初始化搞混了。請看下邊的示例，你可以看到表示通訊錄中一個條目的類的構(gòu)造器：

上邊的做法可以使得 ABEntry 的對象包含你所期望的值，但是這仍不是最優(yōu)的做法。 C++ 的規(guī) 則約定一個對象的數(shù)據(jù)成員要在進(jìn)入構(gòu)造器內(nèi)部之前得到初始化。在 ABEntry 的構(gòu)造器內(nèi)部， theName 、 theAddress 以及 thePhones 并不是得到了初始化，而是被賦值了。初始化工作應(yīng)該在更早的時候進(jìn)行：在進(jìn)入 ABEntry 構(gòu)造器內(nèi)部之前，這些數(shù)據(jù)成員的默認(rèn)構(gòu)造器應(yīng)該自動得到調(diào)用。注意這對于 numTimesConsulted 不成立，因?yàn)樗莾?nèi)建數(shù)據(jù)類型的。對它而言，在被賦值以前，誰也不能確保它得到了初始化。

編寫 ABEntry 的構(gòu)造器的更好的辦法是使用成員初始化表，而不是為它們一一賦值：

如果僅看運(yùn)行結(jié)果，上面的構(gòu)造器與更靠前一些的那個是等價(jià)的，但是后者的效率更高些。為數(shù)據(jù)成員賦值的版本首先調(diào)用了 theName 、 theAddress 以及 thePhones 的默認(rèn)構(gòu)造器來初始化它們，在默認(rèn)構(gòu)造器已經(jīng)為它們分配好了值之后，立即又為它們重新賦了一遍值。于是默認(rèn)構(gòu)造器的所有工作就都白費(fèi)了。使用成員初始化表的方法可以避免這一浪費(fèi)，這是因?yàn)椋撼跏蓟碇械膮?shù)對于各種數(shù)據(jù)成員均使用構(gòu)造器參數(shù)的形式出現(xiàn)。這樣， theName 就通過復(fù)制 name 的值完成了構(gòu)造， theAddress 通過復(fù)制 address 的值完成構(gòu)造， thePhones 通過復(fù)制 phones 的值完成構(gòu)造。對于大多數(shù)類型而言，通過單一的調(diào)用拷貝構(gòu)造器更加高效——在一些情況下尤其明顯——相對于首先調(diào)用默認(rèn)構(gòu)造器，然后再調(diào)用拷貝運(yùn)算符而言。

對于內(nèi)建類型的對象，比如 numTimeConsulted ，初始化與賦值的開銷是完全相同的，但是為了保證持久性，最好在初始化時不要忘記這類成員。類似地，即使你期望讓默認(rèn)構(gòu)造器來構(gòu)造一個數(shù)據(jù)成員，你仍可以使用成員初始化表，只是不為初始化參數(shù)指定一個具體的值而已。比如，如果 ABEntry 擁有一個無參構(gòu)造器，它可以這樣實(shí)現(xiàn)：

這是因?yàn)椋寒?dāng)用戶定義類型的數(shù)據(jù)成員沒有構(gòu)造器列在成員初始化表中的時候，編譯器會自動為其調(diào)用默認(rèn)構(gòu)造器，一些程序員認(rèn)為這樣做有些過分了。這可以理解。但是“總將每個數(shù)據(jù)成員列在初始化表中”這一策略可以使你不必在出現(xiàn)疏忽以后，返回去查找哪些數(shù)據(jù)成員沒有進(jìn)行初始化——疏忽是不存在的。比如說，如果你因?yàn)?/span> numTimesConsulted 是內(nèi)建數(shù)據(jù)類型的，就不將其列入成員初始化表中，那么你的代碼便極有可能呈現(xiàn)出無法預(yù)知的行為。

有些時候必須使用初始化表，即使是對于內(nèi)建類型。舉例說， const 或者引用的數(shù)據(jù)成員必須得到初始化。它們不能被賦值（另請參看第 5 項(xiàng)）。對于那些既可以初始化又可以賦值的數(shù)據(jù)成員，為了省去記憶何時必須使用成員初始化表來初始化它們，最簡便的選擇就是永遠(yuǎn)都使用初始化表。一些時候初始化表是必須的，在更多情況下這樣做是為了獲得比賦值更高的效率。

許多類設(shè)計(jì)有多個構(gòu)造器，每個構(gòu)造器都有自己的成員初始化表。如果有非常多的數(shù)據(jù)成員和 / 或基類時，就會存在多個初始化表，這時列表中將存在不少無意義的重復(fù)，程序員們也會變得十分厭煩。在這種情況下，你也可以考慮忽略表中的一些項(xiàng)目，這些忽略的數(shù)據(jù)成員應(yīng)符合這一條件：對它們進(jìn)行賦值還是真正的初始化沒有什么差別?？梢园堰@些賦值語句放在一個單一（當(dāng)然是私有的）的函數(shù)里，并讓所有的構(gòu)造器在必要的時候調(diào)用這個函數(shù)。這一方法在數(shù)據(jù)成員要接收的真實(shí)的初始化數(shù)據(jù)保存在一個文件中，或者要到一個數(shù)據(jù)庫中去查找時，尤其有用。但是大致上講，真正的成員初始化終究要比通過賦值進(jìn)行偽初始化要好。

C++ 還是存在 穩(wěn)定的方面的，其中之一就是：對象中數(shù)據(jù)的初始化的順序是恒定的。這個次序通常情況下是這樣的：基類應(yīng)在派生類之前得到初始化（另參見第 12 項(xiàng)），在類的內(nèi)部，數(shù)據(jù)成員應(yīng)以它們聲明的順序得到初始化。比如說在 ABEntry 內(nèi)部， theName 永遠(yuǎn)都是第一個得到初始化的， theAddress 第二， thePhones 第三， numTimesConsulted 最后。即使它們在成員初始化表中的排列順序不同于聲明次序，（這樣做看上去不應(yīng)該算作法，但不幸的是事實(shí)不是這樣。）上述初始化順序也會得到遵循。為了不使讀者陷入困惑，也為了避免日后出現(xiàn)讓人難以理解的 bug ，你應(yīng)該保證初始化表中成員的順序與它們被聲明時的順序嚴(yán)格一致。

在你完成了對內(nèi)建類型的非成員對象的顯式初始化，并且確保了構(gòu)造器使用成員初始化表對基類和數(shù)據(jù)成員進(jìn)行了初始化之后，需要你關(guān)心的工作就僅剩下了一個，那就是（先長舒一口氣）：在不同的置換單元中，非局部靜態(tài)對象的初始化次序是怎樣的。

讓我們一步一步地解決這個問題：

一個靜態(tài)對象在被構(gòu)造之后，它的壽命一直延續(xù)到程序結(jié)束。保存在棧或堆中的對象都不是這樣。靜態(tài)對象包括：全局對象、名字空間域?qū)ο蟆㈩悆?nèi)部的 static 對象、函數(shù)內(nèi)部的 static 對象，文件域的 static 對象。函數(shù)內(nèi)部的靜態(tài)對象通常叫做局部靜態(tài)對象（這是因?yàn)樗鼈儗τ诤瘮?shù)而言是局部的），其它類型的靜態(tài)對象稱為非局部靜態(tài)對象。靜態(tài)對象在程序退出的時候會被自動銷毀，換句話說，在 main 中止運(yùn)行的時候，靜態(tài)對象的析構(gòu)器會自動得到調(diào)用。

一個置換單元是這樣一段源代碼：由它可以生成一個目標(biāo)文件。通常一個置換單元是以單一一個代碼文件為基礎(chǔ)，還要包括所有被 #include 進(jìn)來的文件。

于是，我們所要解決的問題中，至少包含兩個需要單獨(dú)編譯的源碼文件，每一個都至少包含一個非局部靜態(tài)對象（換句話說，是一個全局的，或者名字空間域的，抑或類內(nèi)部或者文件域的 static 對象）。問題的本質(zhì)在于：如果一個置換單元內(nèi)的一個非局部靜態(tài)對象的初始化工作利用了另一個置換空間內(nèi)的另一個非局部靜態(tài)變量，那么所使用的對象應(yīng)該是未經(jīng)初始化的，這是因?yàn)椋?em>定義在不同置換單元內(nèi)的非靜態(tài)對象的初始化工作的順序是未定義的。

這里一個示例可以幫助我們理解這一問題。假設(shè)你編寫了一個 FileSystem 類，它可以讓 Internet 上的文件看上去像是本地的。由于你的類要使得整個世界看上去像是一個單一的文件系統(tǒng)，你應(yīng)該創(chuàng)建一個專門的類來代表這個單一的文件系統(tǒng)，讓這個類擁有全局的或者名字空間的作用域：

一個 FileSystem 對象絕對是重量級的，所以說在 tfs 對象被構(gòu)造之前使用它會帶來災(zāi)難性后果。

現(xiàn)在設(shè)想一下，一些客戶端程序員為文件系統(tǒng)創(chuàng)建了一個文件夾的類。很自然地，他們的類會使用 tfs 對象。

進(jìn)一步設(shè)想， 客戶端程序員 可能會為臨時文件創(chuàng)建 一個單獨(dú)的 Directory 對象：

現(xiàn)在，出示化次序的重要性已然浮出水面：除非 tfs 在 tempDir 得到初始化， tempDir 的構(gòu)造器將會嘗試在 tfs 被初始化之前使用它。但是 tfs 和 tempDir 是由不同的人、在不同的時間、在不同的源碼文件中創(chuàng)建的——這兩者都是非局部靜態(tài)對象，它們定義于不同的置換單元中。那么你如何保證 tfs 在 tempDir 之前得到初始化呢？

事實(shí)上這是不可能的。重申一遍， 定義在不同置換單元內(nèi)的非靜態(tài)對象的初始化工作的順序是未定義的 。當(dāng)然這是有理由的：為非局部靜態(tài)對象確定“恰當(dāng)?shù)?#8221;初始化順序是一件很有難度的工作。非常有難度。根本無法解決。在其大多數(shù)形式——由隱式模板實(shí)例化產(chǎn)生的多個置換單元和非局部靜態(tài)對象（也許它們是自己產(chǎn)生的，只是產(chǎn)生的過程借助了隱式模板實(shí)例化的力量）——這不僅使得確認(rèn)初始化的順序變得不可能，甚至尋找一種可行的初始化順序的特殊情況，都顯得毫無意義。

幸運(yùn)的是，一個小小的方法可以完全排除這個難題。所要做的僅僅是把每個非局部靜態(tài)對象移入為它創(chuàng)建的專用函數(shù)中，函數(shù)要聲明為 static 的。這些函數(shù)返回一個它們所包含的對象的引用。于是客戶端程序員就可以調(diào)用這些函數(shù)，而不是直接使用那些對象。也就是說，非局部靜態(tài)對象被局部靜態(tài)對象取代了。（設(shè)計(jì)模式迷們很容易發(fā)現(xiàn)，這是 Singleton 模式一個通用實(shí)現(xiàn)。）

這一方法基于 C++ 的一個約定，那就是：對 于局部靜態(tài)對象來說， 在其被上述函數(shù)調(diào)用的時候，程序中第一次引入了對 該對象的定義，它在此時就一定會得到初始化。所以說對于局部靜態(tài)對象，如果你不使用直接訪問，而改用“通過函數(shù)返回的引用來調(diào)用”，你就保證了你得到的這一引用所引用的是一個經(jīng)初始化的對象。作為獎勵，如果你從未調(diào)用過模仿非局部靜態(tài)對象的函數(shù)，你的程序就永遠(yuǎn)不會引入對這類對象進(jìn)行構(gòu)造和析構(gòu)的開銷，而這對于真正的非局部靜態(tài)對象來說是不可能的。

下面是對這一技術(shù)的應(yīng)用，以 tfs 和 tempDir 為示例：

這一改進(jìn)系統(tǒng)不需要客戶端程序員做出任何改變，除了他們所引用的是 tfs() 和 tempDir() 而不是 tfs 和 tempDir 。也就是說，他們使用的是函數(shù)返回的引用而不是直接使用對象本身。

編寫這一類返回引用的函數(shù)所需要遵循的方針總是十分簡單的 ：在第 1 行定義和初始化一個局部靜態(tài)對象，在第 2 行返回它的引用。如 此的簡單易用使得這類函數(shù)非常適合作為內(nèi)聯(lián)函數(shù)，尤其是對它們的調(diào)用非常頻繁時（參見第 30 項(xiàng)）。另外，這些函數(shù)中包含著靜態(tài)對象，在多線程系統(tǒng)中它們也許會遇到問題。在此聲明，任何種類的非 const 靜態(tài)對象，無論是局部的還是非局部的，它們面對多線程都會碰到這樣那樣的問題。解決這一問題的方法之一是：在程序還以單線程狀態(tài)運(yùn)行時，手動調(diào)用所有的這類返回引用的函數(shù)。這可以排除與初始化相關(guān)的競爭狀態(tài)的出現(xiàn)。

當(dāng)然，使用此類返回引用的函數(shù)來防止初始化次序問題的理念，首先基于此處存在一個合理的初始化次序。如果你的 系統(tǒng)要求對象 A 必須在對象 B 之前得到初始化，但是 A 的初始化需要以 B 的初始化 為前提，你將會面臨一個問題，坦白說，你是咎由自取。然而，如果你能夠駕馭這一不正常的境況，這里介紹的解決方法仍然可以良好的為你服務(wù)，至少對于單線程應(yīng)用程序來說是這樣的。

為了避免在對象初始化之前使用它，你僅僅需要做三件事。第一，手動初始化基本類型的非成員對象。第二，使用成員初始化表來初始化對象的每一部分。最后，初始化次序的不確定性會使定義于不同置換單元中的非局部靜態(tài)對象之間產(chǎn)生沖突，要避免這樣的設(shè)計(jì)。

需要記住的

l 由于 C++ 只在某些情況下對于基本類型對象進(jìn)行初始化，所以對它們要進(jìn)行手動初始化。

l 對于構(gòu)造器，要盡量使用成員初始化表，避免在構(gòu)造器內(nèi)部進(jìn)行復(fù)制。初始化表中的次序要與成員在類中被聲明的次序相一致。

l 要避免跨置換單元的初始化次序問題發(fā)生，可以使用局部靜態(tài)對象來代替非局部靜態(tài)對象。