条款47: 确保非局部静态对象在使用前被初始化

条款47: 确保非局部静态对象在使用前被初始化

大家都是成年人了，所以用不着我来告诉你们：使用未被初始化的对象无异于蛮干。事实上，关于这个问题的整个想法会让你觉得可笑；构造函数可以确保对象在创建时被初始化，难道不是这样吗？

唔，是，也不是。在某个特定的被编译单元（即，源文件）中，可能一切都不成问题；但如果在某个被编译单元中，一个对象的初始化要依赖于另一个被编译单元中的另一个对象的值，并且这第二个对象本身也需要初始化，事情就会变得更复杂。

例如，假设你已经写了这样一个程序库，它提供一个文件系统的抽象，其中可能包括一个功能，使得互联网上的文件看起来就象在本地一样。既然程序库使得整个世界看起来象一个单独的文件系统，你就可以在程序库的名字空间（见条款28）中创建一个专门的对象，theFileSystem，这样，用户任何时候需要和程序库所提供的文件系统交互，都可以使用它：

class FileSystem { ... }; // 在个类在你
// 的程序库中

FileSystem theFileSystem; // 程序库用户
// 和这个对象交互

因为theFileSystem表示的是很复杂的东西，所以它的构造重要而且必需；在theFileSystem还没构造之前就使用它会造成不可确定的行为。（然而，参考条款M17，象theFileSystem这样的对象，其初始化可以被有效、安全地延迟。）

现在假设某个程序库的用户创建了一个类，表示文件系统中的目录。很自然地，这个类使用了theFileSystem：

class Directory { // 由程序库的用户创建
public:
Directory();
...
};

Directory::Directory()
{
通过调用theFileSystem的成员函数
创建一个Directory对象;
}

进一步假设用户想为临时文件专门创建一个全局Directory对象：

Directory tempDir; // 临时文件目录

现在，初始化顺序的问题变得很明显了：除非theFileSystem在tempDir之前被初始化，否则，tempDir的构造函数将会去使用还没被初始化的theFileSystem。但theFileSystem和tempDir是由不同的人在不同的时间、不同的文件中创建的。怎么可以确认theFileSystem在tempDir之前被创建呢？

任何时候，如果在不同的被编译单元中定义了 "非局部静态对象" ，并且这些对象的正确行为依赖于它们被初始化的某一特定顺序，这类问题就会产生。非局部静态对象指的是这样的对象：

· 定义在全局或名字空间范围内（例如：theFileSystem和tempDir），
· 在一个类中被声明为static，或，
· 在一个文件范围被定义为static。

很抱歉，"非局部静态对象" 这个术语没有简称，所以你要让自己习惯这种有点咬口的句子。

对于不同被编译单元中的非局部静态对象，你一定不希望自己的程序行为依赖于它们的初始化顺序，因为你无法控制这种顺序。让我再重复一遍：你绝对无法控制不同被编译单元中非局部静态对象的初始化顺序。

很自然地想知道，为什么无法控制？

这是因为，确定非局部静态对象初始化的 " 正确" 顺序很困难，非常困难，极其困难。即使在它最普通的形式下 ---- 多个被编译单元，多个通过隐式模板实例化所生成的非局部静态对象（隐式模板实例化时，它们本身可能都会产生这样的问题） ---- 不仅不可能确定正确的初始化顺序，往往连找一个可以确定正确顺序的特殊情况都不值得。

在 "混沌理论" 领域，有一个原理称为 "蝴蝶效应" 。这条原理声称，世界某个角落的一只蝴蝶拍动翅膀，会对大气产生微小的影响，从而导致某个遥远的地方天气模式的深刻变化。稍微准确一点来说也就是：对于某种系统，输入的微小干扰会导致输出彻底的变化。

软件系统的开发也表现了自身的 "蝴蝶效应"。一些系统对需求的细节高度敏感，需求发生细小的变化，实现系统的难易程度就会发生巨大的变化。例如，条款29说明，将一个隐式转换的要求从 "String到char*" 改为 "String到const char*"，就可以将一个运行慢、容易出错的函数用一个运行快并且安全的函数来代替。

确保非局部静态对象在使用前被初始化的问题也和上面一样，它对你的实现细节十分敏感。但是，如果你不强求一定要访问 "非局部静态对象"，而愿意访问具有和非局部静态对象 "相似行为" 的对象（不存在初始化问题），难题就消失了。取而代之的是一个很容易解决的问题，甚至称不上是一个问题。

这种技术 ---- 有时称为 "单一模式"（译注：即Singleton pattern，参见 "Design Patterns" 一书）---- 本身很简单。首先，把每个非局部静态对象转移到函数中，声明它为static。其次，让函数返回这个对象的引用。这样，用户将通过函数调用来指明对象。换句话说，用函数内部的static对象取代了非局部静态对象。（参见条款M26）

这个方法基于这样的事实：虽然关于 "非局部" 静态对象什么时候被初始化，C++几乎没有做过说明；但对于函数中的静态对象（即，"局部" 静态对象）什么时候被初始化，C++却明确指出：它们在函数调用过程中初次碰到对象的定义时被初始化。所以，如果你不对非局部静态对象直接访问，而用返回局部静态对象引用的函数调用来代替，就能保证从函数得到的引用指向的是被初始化了的对象。这样做的另一个好处是，如果这个模拟非局部静态对象的函数从没有被调用，也就永远不会带来对象构造和销毁的开销；而对于非局部静态对象来说就没有这样的好事。

下面的代码对theFileSystem和tempDir都采用了这一技术：

class FileSystem { ... }; // 同前
FileSystem& theFileSystem() // 这个函数代替了
{ // theFileSystem对象

static FileSystem tfs; // 定义和初始化
// 局部静态对象
// (tfs = "the file system")

return tfs; // 返回它的引用
}

class Directory { ... }; // 同前

Directory::Directory()
{
同前，除了theFileSystem被
theFileSystem()代替;
}

Directory& tempDir() // 这个函数代替了
{ // tempDir对象

static Directory td; // 定义和初始化
// 局部静态对象

return td; // 返回它的引用
}

系统被修改后，用户还是完全和以前一样编程，只是现在他们用的是theFileSystem()和tempDir()，而不是theFileSystem和tempDir。即，他们所用的是返回对象引用的函数，而不是对象本身。

这种返回引用的函数虽然采用了上面所讨论的技术，但函数本身总是很简单：第一行定义并初始化一个局部静态对象，第二行返回它，仅此而已。因为太简单，你可能很想把它声明为inline。条款33指出，对于C++语言规范的最新修订版本来说，这是一个非常有效的实现策略；但它同时指出，在使用之前，一定要确认你的编译器和标准中的相关要求要一致。如果编译器不符合最新标准，你又象上面那样使用内联，就可能造成函数以及函数内部静态对象有多份拷贝。这足以让一个成年的程序员哭泣。

至此已没有什么神秘之处了。为了使这一技术有效，一定要给对象一个合理的初始化顺序。如果你让对象A必须在对象B之前初始化，同时又让A的初始化依赖于B已经被初始化，你就会惹上麻烦，坦白说，是罪有应得。如果能避开这种不合理的情况，本条款所介绍的方案将会很好地为你提供帮助。