Item 04：确定对象被使用前已先被初始化
眼
Item 04： Make sure that objects are initialized before they're used
读取未初始化的值会导致不明确的行为。而最佳的处理办法就是：永远在使用对象之前先将它初始化。
对于内置类型，你必须手工完成此事。
对于内置类型以外的任何其他东西，初始化责任落在构造函数身上。规则很简答：确保每一个构造函数都将对象的每一个成员初始化。
赋值和初始化
“确保每一个构造函数都将对象的每一个成员初始化”看起来很容易奉行，重要的是别混淆了赋值和初始化。
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 numTimesConsulted;
};
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构造函数本体的时间更早）。
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为初值进行copy构造，theAddress以address为初值进行copy构造，thePhones以ponoes为初值进行copy构造。
对大多数类型而言，比起先调用默认构造函数然后再调用赋值操作符，仅仅调用一次copy构造函数是比较高效的，有时甚至高效的多。对于内置类型对象如numTimesConsulted，其初始化和赋值的成本相同，但为了一致性最好也通过成员初始化列表来初始化。
同样道理，甚至当你想要默认构造一个成员变量，你都可以使用成员列表初始化，只要指定无物作为初始化实参即可。加入ABEntry有一个无参数构造函数：
ABEntry::ABEntry()
: theName(), //调用theName的默认构造函数;
theAddress(), //调用theAddress的默认构造函数;
thePhones(), //调用thePhones的默认构造函数;
numTimesConsulted(0) //显示初始化为0
{}
由于编译器会为用户自定义类型之成员变量自动调用默认构造函数——如果那些成员变量在“成员初始化列表”中没有被指定初值的话，因而引发某些程序员夸张地采用以上写法。这是可以理解的，但是一定要在成员初始化列表中列出所有成员变量，以免还得记住哪些成员变量可以无需初值。例如，由于numTimesConsulted属于内置类型，如果成员初始化列表遗漏了它，它就没有初值，因此可能会开启“不明确行为”的潘多拉盒子。
有些情况下，即使面对的成员变量属于内置类型（那么其初始化与赋值的成本相同），也一定得使用初始化类表。是的，如果成员变量是const或reference，它们就一定需要初值，不能被赋值。为避免需要记住成员变量何时必须在成员初始化列表中初始化，何时不需要，最简单粗暴的做法是：总是使用成员初始化列表。这样做有时候绝对必要，而且又往往比赋值更高效。
成员初始化次序
C++有着固定的“成员初始化次序”。次序总是相同：base classes更早与其dderived classes被初始化，而class的成员变量总是以其声明次序被初始化。看看ABEntry，其theName成员永远最先被初始化，然后是theAddress，再来是thePhone，最后是numTimesConsulted。即使它们在成员初始化列表中以不同的次序出现（编译器会报出警告），也不会有任何影响（只是报出警告）。为了避免代码阅读者的疑惑，或者必须一些晦涩错误（两个成员变量的初始化带有次序性，例如初始化数组时需要指定大小，因此代表大小的那个成员变量必须先有初值），当你在成员初始化列表中列出各个成员时，最好总是以其声明次序为次序。
每个成员在构造函数初始化列表中只能指定一次。构造函数初始化列表仅指定用于初始化成员的值，并不指定这些初始化执行的次序。成员被初始化的次序就是定义成员的次序。
————《C++ Primer》第四版 P389
不同编译单元内定义的non-local static对象的初始化次序
一旦你已经很小心地将“内置型成员变量”明确地加以初始化，而且也确保你的构造函数运用成员初始化列表初始化base classes和成员变量，那就只剩下一件事需要担心了，就是————“不同编译单元内定义的non-local static对象”的初始化次序。
所谓static对象
所谓static对象，其寿命从被构造出来直到程序结束为止，因此stack和heap-based对象都被排除。这种对象包括global对象、定义与namespace作用域内的对象、在classes内、在函数内、以及在file作用域内被声明为static的对象。函数内的static对象称为local static对象，其他static对象称为non-local static对象。程序结束时static对象会被自动销毁，也就是它们的析构函数会在main()结束时被自动调用。
所谓编译单元
所谓便一单元是指产出单一目标文件的那些源码。基本上它是单一源码文件加上其所含入的头文件。
现在，我们关心的问题涉及至少两个源码文件，每一个内含至少一个non-local static对象（也就是说该对象是global或位于namespace作用域内，抑或在class内或file作用域内被声明为static）。真正的问题是：如果某编译单元内的某个non-local static对象的初始化动作使用了另一个编译单元内的某个non-local static对象，它所用到的这个对象可能尚未被初始化，因为C++对“定义不同编译单元内的non-local static对象”的初始化次序并无明确定义。
假设你有一个FileSystem class，它让互联网上的文件看起来好像位于本机。由于这个class使世界看起来像个单一文件系统，你可能会产出一个特殊对象，位于global或namespace作用域内，象征单一文件系统：
class FileSystem { // from your library’s header file
public:
...
std::size_t numDisks() const; // one of many member functions
...
};
extern FileSystem tfs; // declare object for clients to use
// (“tfs” = “the file system” );
// definition is in some .cpp file in your library
现在假设某些客户建立了一个class用以处理文件系统内的目录。很自然它们的class会用上tfs对象。
class Directory { // created by library client
public:
Directory( params );
...
};
Directory::Directory( params )
{
...
std::size_t disks = tfs.numDisks(); // use the tfs object
...
}
进一步假设，这些客户决定创建一个Directory对象，用来放置临时文件：
Directory tempDir( params ); //directory for temporary files
现在初始化次序的重要性显现出来了：除非tfs在tempDir之前先被初始化，否则tempDir的构造函数会用到尚未初始化的tfs。但tfs和tempDir是不同的人在不同的时间于不同的源码文件建立起来的，它们是定义于不同编译单元内的non-local static对象。如何能够确定tfs会在tempDir之前先被初始化？
local static 替换 non-local static
幸运的是一个小小的设计可以完全消除这个问题。唯一需要做的是：将每个non-local static对象搬到自己的专属函数内（该对象在此函数内被声明为static）。这些函数返回一个reference指向它所含的对象。然后用户调用这些函数，而不直接指涉这些对象。换句话说，non-local static对象被local static对象替换了。这就是Singleton模式（单例模式）的一个常见手法。
这个手法的基础在于：C++保证，函数内的local static对象会在“该函数被调用期间”“首次遇上该对象之定义式”时被初始化。所以如果你以“函数调用”（返回一个reference指向local static对象）替换“直接访问non-local static对象”，你就获得了保证，保证你所获得的那个reference将指向一个历经初始化的对象。更棒的是，如果你从未调用non-local static对象的“仿真函数”，就绝不会引发构造和析构成本；真正的non-local static对象可没这等便宜！
class FileSystem { ... }; // as before
FileSystem& tfs() // this replaces the tfs object; it could be
{ // static in the FileSystem class
static FileSystem fs; // define and initialize a local static object
return fs; // return a reference to it
}
class Directory { ... }; // as before
Directory::Directory( params ) // as before, except references to tfs are
{ // now to tfs()
...
std::size_t disks = tfs().numDisks();
...
}
Directory& tempDir() // this replaces the tempDir object; it
{ // could be static in the Directory class
static Directory td( params ); // define/initialize local static object
return td; // return reference to it
}
这种结构下的reference-returning函数往往十分单纯：第一行定义并初始化一个local static对象，第二行返回它。这样的单纯性使它们称为绝佳的inline候选人，尤其如果它们被频繁调用的话。但是从另一个角度看，这些函数“内含static对象”的事实使它们在多线程系统中带有不确定性。任何一种non-const static对象，不论它是local或non-local，在多线程环境下“等待某事发生”都会有麻烦。处理这个麻烦的一种做法是：在程序的单线程启动阶段手工调用所有reference-returning函数，这可消除与初始化有关的“竞速形势”。
运用reference-returning函数防止“初始化次序问题”，前提是其中有着一个对对象而言合理的初始化次序。如果你有一个系统，其中对象A必须在对象B之前先初始化，但A的初始化能否成功却又受制于B是否已初始化，这时候你就有麻烦了。坦白说你自作自受。只要避开如此病态的境况，此处描述的办法应该可以提供你良好的服务，至少在单线程程序中。
Note
- 为内置型对象进行手工初始化，因为C++不保证初始化它们。
- 构造函数最好使用成员初始化列表，而不要在构造函数本体内使用赋值操作。初始化列表中列出的成员变量，其排列次序应该和它们在class中的声明次序相同。
- 为免除“跨编译单元之初始化次序”问题，请以local static对象替换non-local static对象。
Effective C++
