C++在對象值的初始化問題上顯得變幻莫測。比如說，你寫下了下面的代碼：
在一些上下文里，x會確保得到初始化（為零），但是另一些情況下則不會，如果你這樣編寫：
class Point {
int x, y;
};
...
Point p;
p的數據成員在一些情況下會確保得到初始化（為零），但是另一些情況則不會。如果你以前學習的語言沒有對象初始化的概念，那么請你注意了，因為這很重要。
讀取未初始化的數據將導致未定義行為。在一些語言平臺中，通常情況下讀取未初始化的數據僅僅是使你的程序無法運行罷了。更典型的情況是，這樣的讀取操作可能會得到內存中某些位置上的半隨機的數據，這些數據將會“污染”需要賦值的對象，最終，程序的行為將變得十分令人費解，你也會陷入煩人的除錯工作中。
現在，人們制定了規則來規定對象在什么時候必須被初始化，以及什么時候不會。但是遺憾的是，這些規則太過復雜了——在我看來，你根本沒必要去記憶它們。整體上講，如果你正在使用C++中C語言的一部分（參見條目1），并且這里的初始化會引入運行時開銷，那么此時初始化工作無法確保完成。但當你使用非C的C++部分時，情況有時就會改變。這便可以解釋為什么數組（C++中的C語言）不會確保得到初始化，而一個vector（C++中的STL）會。
解決這類表面上的不確定性問題最好的途徑就是：總是在使用對象之前對它們進行初始化。對于內建類型的非成員對象，你需要手動完成這一工作。請看下邊的示例：
int x = 0; // 手動初始化一個int值
const char * text = "A C-style string"; // 手動初始化一個指針（見條目3）
double d;
std::cin >> d; // 通過讀取輸入流進行“初始化”
對于其他大多數情況而言，初始化的重擔就落在了構造函數的肩上。這里的規則很簡單：確保所有構造函數都對整個對象做出完整的初始化。
遵守這一規則是件很容易的事情，但是還有件重要的事：不要把賦值和初始化搞混了。請看下邊示例中的構造函數，它是通訊錄中用于表示條目的類：
class PhoneNumber { ... };
class ABEntry { // ABEntry = "Address Book Entry"
public:
ABEntry(const std::string& name, const std::string& address,
const std::list<PhoneNumber>& phones);
private:
std::string theName;
std::string theAddress;
std::list<PhoneNumber> thePhones;
int num TimesConsulted;
};
ABEntry::ABEntry(const std::string& name, const std::string& address,
const std::list<PhoneNumber>& phones)
{
theName = name; // 以下這些是賦值，而不是初始化
theAddress = address;
thePhones = phones;
numTimesConsulted = 0;
}
上邊的做法可以讓你得到一個包含你所期望值的ABEntry對象，但是這仍不是最優的做法。C++的規則約定：一個對象的數據成員要在進入構造函數內部之前得到初始化。在ABEntry的構造函數內部，theName、theAddress以及thePhones并不是得到了初始化，而是被賦值了。初始化工作應該在更早的時候進行：在進入ABEntry構造函數內部之前，這些數據成員的默認構造函數應該自動得到調用。注意這對于numTimesConsulted不成立，因為它是內建數據類型的。對它而言，在被賦值以前，誰也不能確保它得到了初始化。
編寫ABEntry的構造函數的一個更好的辦法是使用成員初始化表，而不是為成員一一賦值：
ABEntry::ABEntry(const std::string& name, const std::string& address,
const std::list<PhoneNumber>& phones)
: theName(name),
theAddress(address), // 現在這些是初始化
thePhones(phones),
numTimesConsulted(0)
{} // 現在構造函數內部是空的
如果僅看運行結果，上面的構造函數與更靠前一些的那個是一樣的，但是后者的效率更高些。為數據成員賦值的版本首先調用了theName、theAddress以及thePhones的默認構造函數來初始化它們，在默認構造函數已經為它們分配好了值之后，立即又為它們重新賦了一遍值。于是默認構造函數的所有工作就都白費了。使用成員初始化表的方法可以避免這一浪費，這是因為：初始化表中的參數對于各種數據成員均使用構造函數參數的形式出現。這樣，theName就通過復制name的值完成了構造，theAddress通過復制address的值完成構造，thePhones通過復制phones的值完成構造。對于大多數類型來說，相對于“先調用默認構造函數再調用拷貝運算符”而言，通過單一的調用拷貝構造函數更加高效——在一些情況下尤其明顯。
對于內建類型的對象，比如numTimeConsulted，初始化與賦值的開銷是完全相同的，但是為了保證程序的一致性，最好通過成員初始化的方式對所有成員進行初始化。類似地，即使你期望讓默認構造函數來構造一個數據成員，你仍可以使用成員初始化表，只是不為初始化參數指定一個具體的值而已。比如，如果ABEntry擁有一個沒有參數的構造函數，它可以這樣實現：
ABEntry::ABEntry()
:theName(), // 調用theName的默認構造函數；
theAddress(), // theAddress和thePhones同上；
thePhones(), // 但是numTimesConsulted
numTimesConsulted(0) // 一定要顯性初始化為零
{}
由于成員初始化表中沒有為用戶定義類型的數據成員指定初始值時，編譯器會自動為這些成員調用默認構造函數，因此一些程序員會認為上文中的做法顯得有些多余。這是可以理解的，但是“總將每個數據成員列在初始化表中”這一策略可以避免你去回憶列表中是哪個成員被忽略了從而無法得到初始化。比如說，如果你因為numTimesConsulted是內建數據類型的，就不將其列入成員初始化表中，那么你的代碼便極有可能呈現出未定義行為。
有些時候使用初始化表是必須的，即使是對于內建類型。舉例說，const或者引用的數據成員必須得到初始化，它們不能被賦值（另請參看條目5）。至于數據成員什么時候必須在成員初始化表中進行初始化，什么時候沒有必要，如果你不希望去記憶這些規則，那么最簡便的選擇就是永遠都使用初始化表。一些時候初始化表是必須的，而且通常會獲得比賦值更高的效率。
許多類都包含多個構造函數，每個構造函數都有自己的成員初始化表。如果某個類擁有非常多的數據成員和/或基類時，這些初始化列表中將會存在不少無意義的重復代碼，程序員們也會感到厭煩。在這種情況下，忽略表中的一些條目也并非毫無意義，這些忽略的數據成員應符合這一條件：對它們進行賦值還是真正的初始化沒有什么差別。可以把這些賦值語句放在一個單一（當然是私有的）的函數里，并讓所有的構造函數在必要的時候調用這個函數。在數據成員要接收的真實的初始化數據需要從某個文件中讀取時，或者要到某個數據庫中去查找時，這一方法尤其有用。但是總體而言，真正的成員初始化終究要比通過賦值進行偽初始化要好。
C++也不是總那么變幻莫測，對象中數據的初始化的順序就是C++的穩定因素之一。這個次序通常情況下是一致的：基類應在派生類之前得到初始化（另參見條目12），在類的內部，數據成員應以它們聲明的順序得到初始化。比如說在ABEntry內部，theName永遠都是第一個得到初始化的，theAddress第二，thePhones第三，numTimesConsulted最后。即使它們在成員初始化表中的排列順序不同于聲明次序，（盡管這樣做看上去應該算作非法，但不幸的是事實并非這樣。）上述初始化順序也會得到遵循。為了不使讀者陷入困惑，也為了避免日后出現讓人難以理解的bug，你應該保證初始化表中成員的順序與它們被聲明時的順序嚴格一致。
在你完成了對內建類型的非成員對象的顯式初始化，并且確保了構造函數使用成員初始化表對基類和數據成員進行了初始化之后，需要你關心的內容就僅剩下了一個，那就是（先長舒一口氣）：在不同的置換單元中，非局部靜態對象的初始化次序是怎樣的。
讓我們來抽絲剝繭分析這個問題：
【靜態對象（static object）】一個靜態對象在被構造之后，它的壽命一直延續到程序結束。保存在棧或堆中的對象都不是這樣。靜態對象包括：全局對象、名字空間域對象、類內部的static對象、函數內部的static對象，文件域的static對象。函數內部的靜態對象通常叫做局部靜態對象（這是因為它們對于函數而言是局部的），其它類型的靜態對象稱為非局部靜態對象。靜態對象在程序退出的時候會被自動銷毀，換句話說，在main中止運行的時候，靜態對象的析構函數會自動得到調用。
【置換單元（translation unit）】一個置換單元是這樣一段源代碼：由它可以生成一個目標文件。總的來說置換單元就是單一一個代碼文件，以及所有被#include進來的文件。
于是，我們所要解決的問題中，至少包含兩個需要單獨編譯的源碼文件，每一個都至少包含一個非局部靜態對象（換句話說，是一個全局的，或者名字空間域的，或類內部或者文件域的static對象）。真正的問題是：如果一個置換單元內的一個非局部靜態對象的初始化工作利用了另一個置換空間內的另一個非局部靜態變量，那么所使用的對象應該是未經初始化的，這是因為：定義在不同置換單元內的非靜態對象的初始化工作的順序是未定義的。
這里一個示例可以幫助我們理解這一問題。假設你編寫了一個FileSystem類，它可以讓Internet上的文件看上去像是本地的。由于你的類要使得整個世界看上去像是一個單一的文件系統，你應該創建一個專門的類來代表這個單一的文件系統，讓這個類擁有全局的或者名字空間的作用域：
class FileSystem { // 來自你的庫
public:
...
std::size_t numDisks() const; // 許多成員函數中的一個
...
};
extern FileSystem tfs; // 供客戶端使用的對象
// "tfs" = "the file system"
一個FileSystem對象絕對是重量級的，所以說在tfs對象被構造之前使用它會帶來災難性后果。
現在設想一下，一些客戶為文件系統創建了一個文件夾的類。很自然地，他們的類會使用tfs對象。
class Directory { // 由類庫的客戶創建
public:
Directory( params );
...
};
Directory::Directory( params )
{
...
std::size_t disks = tfs.numDisks(); // 使用 tfs 對象
...
}
進一步設想，客戶可能會為臨時文件創建一個單獨的Directory對象：
Directory tempDir( params ); // 存放臨時文件的文件夾
現在，初始化次序的重要性已然浮出水面：除非tfs在tempDir初始化之前得到初始化，否則tempDir的構造函數將會嘗試在tfs被初始化之前使用它。但是tfs和tempDir是由不同的人、在不同的時間、在不同的源碼文件中創建的——這兩者都是非局部靜態對象，它們定義于不同的置換單元中。那么你如何保證tfs在tempDir之前得到初始化呢？
事實上這是不可能的。重申一遍，定義在不同置換單元內的非靜態對象的初始化工作的順序是未定義的。當然這是有理由的：為非局部靜態對象確定“恰當的”初始化順序是一件很有難度的工作。非常有難度。難到根本無法解決。在其大多數形式——由隱式模板實例化產生的多個置換單元和非局部靜態對象（也許它們是通過隱式模板實例化自行生成的）——這不僅使得確認初始化的順序變得不可能，甚至尋找一種可行的初始化順序的特殊情況，都顯得毫無意義。
幸運的是，一個小小的方法可以完美的解決這個難題。所要做的僅僅是把每個非局部靜態對象移入為它創建的專用函數中，函數要聲明為static的。這些函數返回一個它們所屬對象的引用。于是客戶就可以調用這些函數，而不是直接使用那些對象。也就是說，非局部靜態對象被局部靜態對象取代了。（設計模式迷們很容易發現，這是單例模式（Singleton Pattern）一個通用實現。）
這一方法基于C++的一個約定，那就是：對于局部靜態對象來說，在其被上述函數調用的時候，程序中第一次引入了該對象的定義，它在此時就一定會得到初始化。所以如果你不去直接訪問非局部靜態對象，而改用“通過函數返回的引用來調用局部靜態對象”，那么你就保證了你得到的這一引用將指向一個已經初始化的對象。作為獎勵，如果你從未調用過模仿非局部靜態對象的函數，你的程序就永遠不會引入對這類對象進行構造和析構的開銷，而這對于真正的非局部靜態對象來說是不可能的。
下面是關于tfs和tempDir對這一技術的應用：
class FileSystem { ... }; // 同上
FileSystem& tfs() // 這一函數代替了tfs對象；它在
// FileSystem類中應該是static的
{
static FileSystem fs; // 對局部靜態對象的定義和初始化
return fs; // 返回該對象的引用
}
class Directory { ... }; // 同上
Directory::Directory( params ) // 同上，但對tfs的引用現在為對tfs()
{
...
std::size_t disks = tfs().numDisks();
...
}
Directory& tempDir() // 這個函數取代了tempDir對象；它在
// Directory類中應該是static的
{
static Directory td; // 對局部靜態對象的定義和初始化
return td; // 返回該對象的引用
}
這一改進系統不需要客戶做出任何改變，除了他們所引用的是tfs()和tempDir()而不是tfs和tempDir。也就是說，他們使用的是返回引用的函數而不是直接使用對象本身。
編寫這一類返回引用的函數所需要遵循的方針總是十分簡單的：第1行定義和初始化一個局部靜態對象，第2行返回它的引用。如此的簡單易用使得這類函數非常適合作為內聯函數，尤其是對它們的調用非常頻繁時（參見條目30）。另外，這些函數中包含著靜態對象，這一事實使得他們在多線程系統中也會遇到問題。在此聲明，任何種類的非const靜態對象，無論是局部的還是非局部的，它們面對多線程都會碰到這樣那樣的問題。解決這一問題的方法之一是：在程序還以單線程狀態運行時，手動調用所有的這類返回引用的函數。這可以排除與初始化相關的競爭狀態的出現。
當然，使用此類返回引用的函數來防止初始化次序問題的理念，首先基于此處存在一個合理的初始化次序。如果你的系統要求對象A必須在對象B之前得到初始化，但是A的初始化需要以B的初始化為前提，你將會面臨一個問題，坦白說，你是咎由自取。然而，如果你能夠駕馭這一不正常的境況，這里介紹的解決方法仍然可以良好的為你服務，至少對于單線程應用程序來說是這樣的。
為了避免在對象初始化之前使用它，你僅僅需要做三件事。第一，手動初始化內建類型的非成員對象。第二，使用成員初始化表來初始化對象的每一部分。最后，初始化順序的不確定性使得定義于不同置換空間里非局部靜態對象難以正常運行，你需要尋求一個新的設計方案。
時刻牢記
l 由于C++只在某些情況下對于內建類型對象進行初始化，所以對它們要進行手動初始化。
l 對于構造函數，要盡量使用成員初始化表，避免在構造函數內部進行復制。初始化表中的次序要與成員在類中被聲明的次序相一致。
l 要避免跨置換單元的初始化次序問題發生，可以使用局部靜態對象來代替非局部靜態對象的方案來解決。