1.如果不初始化会怎样？
关于“将对象初始化”这事，C++似乎反复无常。如果你这么写：int x；
在某些语境下x保证被初始化（为0），但在其他语境中却不保证。如果你这么写：
class Point{
int x,y;
};
...
Point p;p的成员变量有时候被初始化（为 0），有时候不会。如果你来自其他语言阵营而那儿并不存在“无初值对象”，那么请小心，因为这颇为重要。读取未初始化的值会导致不明确的行为。在某些平台上，仅仅只是读取未初始化的值，就可能让你的程序终止运行。更可能的情况是读入一些“半随机”bits，污染了正在进行读取动作的那个对象，最终导致不可测知的程序行为，以及许多令人不愉快的调试过程。现在，我们终于有了一些规则，描述“对象的初始化动作何时一定发生，何时不一定发生”。不幸的是这些规则很复杂，我认为对记忆力而言是太繁复了些。
通常如果你使用C part of C++（见条款1）而且初始化可能招致运行期成本，那么就不保证发生初始化。一旦进入non-C parts of C++，规则有些变化。这就很好地解释了为什么array（来自C part of C++）不保证其内容被初始化，而vector（来自STL part of C++）却有此保证。
表面上这似乎是个无法决定的状态，而最佳处理办法就是：永远在使用对象之前先将它初始化。
2.内置类型的初始化
对于无任何成员的内置类型，你必须手工完成此事。例如：
int x = 0; // 对int进行手工初始化
const char* test = "A C-style string"; // 对指针进行手工初始化
double d;
std::cin>> d; // 以读取输入流的方式完成初始化3.类的初始化
至于内置类型以外的任何其他东西，初始化责任落在构造函数（constructors）身上。规则很简单：确保每一个构造函数都将对象的每一个成员初始化。这个规则很容易奉行，重要的是别混淆了赋值（assignment）和初始化（initialization）。
3.1 构造函数中的赋值操作-非初始化
考虑一个用来表现通讯簿的class，其(拷贝)构造函数如下：
class PhontNumber {};
class ABEntry
{
public:
ABEntry(const std::string& name, const std::string& address,
const std::list<PhontNumber>& phones);
private:
std::string theName;
std::string theAddress;
std::list<PhontNumber> thePhones;
int numTimesConsulted;
};
ABEntry::ABEntry(const std::string& name, const std::string& address,
const std::list<PhontNumber>& phones)
{
theName = name; // 赋值操作，非初始化
theAddress = address; // 赋值操作，非初始化
thePhones = phones; // 赋值操作，非初始化
numTimesConsulted = 0;
}这会导致ABEntry对象带有你期望(你指定)的值，但不是最佳做法。C++规定，对象的成员变量的初始化动作发生在进入构造函数本体之前。在ABEntry构造函数内，theName，theAddress和thePhones都不是被初始化，而是被赋值。初始化的发生时间更早，发生于这些成员的 default 构造函数被自动调用之时（比进入ABEntry构造函数本体的时间更早）。但这对numTimesConsulted不为真，因为它属于内置类型，不保证一定在你所看到的那个赋值动作的时间点之前获得初值。
3.2 构造函数中的真正初始化-成员初始化列表初始化
ABEntry构造函数的一个较佳写法是，使用所谓的member initialization list（成员初值列）替换赋值动作：
class PhontNumber {};
class ABEntry
{
public:
// 成员初始化列表初始化:真正的初始化
ABEntry(const std::string& name, const std::string& address,
const std::list<PhontNumber>& phones)
:theName(name), theAddress(address), thePhones(phones), numTimesConsulted(0)
{}
private:
std::string theName;
std::string theAddress;
std::list<PhontNumber> thePhones;
int numTimesConsulted;
};这个构造函数和上一个的最终结果相同，但通常效率较高。
3.3 以上两个构造函数的效率比较
基于赋值的那个版本（本例第一版本）首先调用default构造函数为theName，theAddress和thePhones设初值，然后立刻再对它们赋予新值。default构造函数的一切作为因此浪费了。成员初值列（member initialization list）的做法（本例第二版本）避免了这一问题，因为初值列中针对各个成员变量而设的实参，被拿去作为各成员变量的构造函数的实参。本例中的theName以name为初值进行 copy构造，theAddress以address为初值进行copy构造，thePhones以phones为初值进行copy构造。对大多数类型而言，比起先调用 default构造函数然后再调用 copy assignment操作符，单只调用一次 copy 构造函数是比较高效的，有时甚至高效得多。对于内置型对象如numTimesConsulted，其初始化和赋值的成本相同，但为了一致性最好也通过成员初值列来初始化。
3.4 一个无参构造的过度紧张写法&记住总是列出所有成员变量
当你想要default构造一个成员变量，你都可以使用成员初值列，只要指定无物（nothing）作为初始化实参即可。假设ABEntry有一个无参数构造函数，我们可将它实现如下：
ABEntry::ABEntry()
:theName(), // 调用theName的default构造函数
theAddress(), // 调用theAddress的default构造函数
thePhone(), // 调用thePhone的default构造函数
numTimeConsulted(0) // 记得将numTimeConsulted显示初始化为0
{}
由于编译器会为用户自定义类型（user-defined types）之成员变量自动调用default构造函数——如果那些成员变量在“成员初值列”中没有被指定初值的话，因而引发某些程序员过度夸张地采用以上写法。那是可理解的，但请立下一个规则，规定总是在初值列中列出所有成员变量，以免还得记住哪些成员变量（如果它们在初值列中被遗漏的话）可以无需初值。举个例子，由于numTimesConsulted属于内置类型，如果成员初值列（member initializationlist）遗漏了它，它就没有初值，因而可能开启“不明确行为”的潘多拉盒子。
3.5 构造函数中一定得使用初值列的情况
有些情况下即使面对的成员变量属于内置类型（那么其初始化与赋值的成本相同），也一定得使用初值列。是的，如果成员变量是const或 references，它们就一定需要初值，不能被赋值（见条款5）。为避免需要记住成员变量何时必须在成员初值列中初始化，何时不需要，最简单的做法就是：总是使用成员初值列。这样做有时候绝对必要，且又往往比赋值更高效。
3.6 有时候也可适当丢掉一些“赋值表现像初始化一样好”的成员变量
许多 classes 拥有多个构造函数，每个构造函数有自己的成员初值列。如果这种classes存在许多成员变量和/或base classes，多份成员初值列的存在就会导致不受欢迎的重复（在初值列内）和无聊的工作（对程序员而言）。这种情况下可以合理地在初值列中遗漏那些“赋值表现像初始化一样好”的成员变量，改用它们的赋值操作，并将那些赋值操作移往某个函数（通常是private），供所有构造函数调用。这种做法在“成员变量的初值系由文件或数据库读入”时特别有用。然而，比起经由赋值操作完成的“伪初始化”（pseudo-initialization），通过成员初值列（member initialization list）完成的“真正初始化”通常更加可取。
4.C++中的成员初始化次序与“跨编译单元之初始化次序”问题
4.1 一些建议
C++有着十分固定的“成员初始化次序”。是的，次序总是相同：base classes更早于其derived classes被初始化（见条款12），而class的成员变量总是以其声明次序被初始化。回头看看 ABEntry，其 theName 成员永远最先被初始化，然后是theAddress，再来是thePhones，最后是numTimesConsulted。即使它们在成员初值列中以不同的次序出现（很不幸那是合法的），也不会有任何影响。为避免你或你的检阅者迷惑，并避免某些可能存在的晦涩错误，当你在成员初值列中条列各个成员时，最好总是以其声明次序为次序。所谓晦涩错误，指的是两个成员变量的初始化带有次序性。例如初始化array时需要指定大小，因此代表大小的那个成员变量必须先有初值。
4.2 不同编译单元内定义的“non-local static对象”的初始化次序
一旦你已经很小心地将“内置型成员变量”明确地加以初始化，而且也确保你的构造函数运用“成员初值列”初始化base classes和成员变量，那就只剩---“不同编译单元内定义之non-local static对象”的初始化次序。
我们关心的问题涉及至少两个源码文件，每一个内含至少一个 non-localstatic对象（也就是说该对象是global或位于namespace作用域内，抑或在class内或 file 作用域内被声明为 static）。真正的问题是：如果某编译单元内的某个non-local static对象的初始化动作使用了另一编译单元内的某个non-local static对象，它所用到的这个对象可能尚未被初始化，因为 C++对“定义于不同编译单元内的non-local static对象”的初始化次序并无明确定义。
概念解释：
static对象(区分local-static对象和non-local-static对象)：
所谓 static 对象，其寿命从被构造出来直到程序结束为止，因此 stack 和heap-based对象都被排除。这种对象包括global对象、定义于namespace作用域内的对象、在classes内、在函数内、以及在file作用域内被声明为static的对象。函数内的static对象称为local static对象（因为它们对函数而言是local），其他static对象称为non-local static对象。程序结束时static对象会被自动销毁，也就是它们的析构函数会在main（）结束时被自动调用。
编译单元：
所谓编译单元（translation unit）是指产出单一目标文件（single object file）的那些源码。基本上它是单一源码文件加上其所含入的头文件（＃include files）。
4.3 从一个实例来看静态对象初始化问题
假设你有一个FileSystem class，它让互联网上的文件看起来好像位于本机（local）。由于这个 class 使世界看起来像个单一文件系统，你可能会产出一个特殊对象，位于global或namespace作用域内，象征单一文件系统：
//FileSystem.h
class FileSystem
{
public:
std::size_t numDisks()const;
};
extern FileSystem tfs;FileSystem 对象绝不是一个稀松平常无关痛痒的（trivial）对象，因此你的客户如果在theFileSystem对象构造完成前就使用它，会得到惨重的灾情。现在假设某些客户建立了一个class用以处理文件系统内的目录（directories）。很自然他们的class会用上theFileSystem对象：
//Directory.h
#include "FileSystem.h"
class Directory
{
public:
Directory();
};
Directory::Directory()
{
std::size_t disks = tfs.numDisks(); //使用tfs对象
}
//现在客户在主程序中创建一个Directory对象，用来放置临时文件
Directory tempDir;问题：
初始化次序的重要性显现出来了：除非tfs在tempDir之前先被初始化，否则tempDir的构造函数会用到尚未初始化的tfs。但tfs和tempDir是不同的人在不同的时间于不同的源码文件建立起来的，它们是定义于不同编译单元内的non-localstatic对象。如何能够确定tfs会在tempDir之前先被初始化？喔，你无法确定。再说一次，C++对“定义于不同的编译单元内的non-localstatic对象”的初始化相对次序并无明确定义。这是有原因的：决定它们的初始化次序相当困难，非常困难，根本无解。在其最常见形式，也就是多个编译单元内的non-local static对象经由“模板隐式具现化，implicit template instantiations”形成（而后者自己可能也是经由“模板隐式具现化”形成），不但不可能决定正确的初始化次序，甚至往往不值得寻找“可决定正确次序”的特殊情况。
4.4 如何解决静态对象的初始化问题
幸运的是一个小小的设计便可完全消除这个问题。唯一需要做的是：将每个non-local static对象搬到自己的专属函数内（该对象在此函数内被声明为static）。这些函数返回一个reference指向它所含的对象。然后用户调用这些函数，而不直接指涉这些对象。换句话说，non-local static对象被local static对象替换了。Design Patterns迷哥迷姊们想必认出来了，这是Singleton模式的一个常见实现手法。这个手法的基础在于：C++保证，函数内的local static对象会在“该函数被调用期间”“首次遇上该对象之定义式”时被初始化。所以如果你以“函数调用”（返回一个reference指向local static对象）替换“直接访问non-local static对象”，你就获得了保证，保证你所获得的那个reference将指向一个历经初始化的对象。更棒的是，如果你从未调用non-local static对象的“仿真函数”，就绝不会引发构造和析构成本；真正的non-local static对象可没这等便宜！
以此技术施行于tfs和tempDir身上，结果如下：
//FileSystem.h
class FileSystem
{
public:
std::size_t numDisks()const;
};
FileSystem& tfs()
{
static FileSystem tfs;
return fs;
}//Directory.h
#include "FileSystem.h"
class Directory
{
public:
Directory();
};
Directory::Directory()
{
std::size_t disks = tfs.numDisks(); //使用tfs对象
}
//这个函数用来替换tempDir对象，它在Directory内部可能是static
Directory& tempDir()
{
static Directory td;
return td;
}这么修改之后，这个系统程序的客户完全像以前一样地用它，唯一不同的是他们现在使用tfs（）和tempDir（）而不再是tfs和tempDir。也就是说他们使用函数返回的“指向static对象”的references，而不再使用static对象自身。这种结构下的 reference-returning函数往往十分单纯：第一行定义并初始化一个local static对象，第二行返回它。这样的单纯性使它们成为绝佳的inlining候选人，尤其如果它们被频繁调用的话（见条款 30）。但是从另一个角度看，这些函数“内含static对象”的事实使它们在多线程系统中带有不确定性。再说一次，任何一种non-const static 对象，不论它是local或non-local，在多线程环境下“等待某事发生”都会有麻烦。处理这个麻烦的一种做法是：在程序的单线程启动阶段（single-threaded startup portion）手工调用所有reference-returning函数，这可消除与初始化有关的“竞速形势（race conditions）”。
当然啦，运用reference-returning函数防止“初始化次序问题”，前提是其中有着一个对对象而言合理的初始化次序。如果你有一个系统，其中对象A必须在对象B之前先初始化，但A的初始化能否成功却又受制于B是否已初始化，这时候你就有麻烦了。坦白说你自作自受。只要避开如此病态的境况，此处描述的办法应该可以提供你良好的服务，至少在单线程程序中。既然这样，为避免在对象初始化之前过早地使用它们，你需要做三件事。第一，手工初始化内置型non-member对象。第二，使用成员初值列（memberinitialization lists）对付对象的所有成分。最后，在“初始化次序不确定性”（这对不同编译单元所定义的non-local static对象是一种折磨）氛围下加强你的设计。
5.总结
■ 为内置型对象进行手工初始化，因为C++不保证初始化它们。
■ 构造函数最好使用成员初值列（member initialization list），而不要在构造函数本体内使用赋值操作（assignment）。初值列列出的成员变量，其排列次序应该和它们在class中的声明次序相同。
■ 为免除“跨编译单元之初始化次序”问题，请以local static对象替换non-local-static对象。