Effective C++ 2e Item47

原创 2001年08月08日 20:45:00

条款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已经被初始化,你就会惹上麻烦,坦白说,是罪有应得。如果能避开这种不合理的情况,本条款所介绍的方案将会很好地为你提供帮助。

Effective C++ 目录

改变旧有的C习惯(Shifting from C to C++) 013 条款1:尽量以 const 和 inline 取代 #define 013 Prefer const and inline...
  • sunrise918
  • sunrise918
  • 2011年08月19日 17:34
  • 492

Effective C++ 2e Item25

条款25: 避免对指针和数字类型重载快速抢答:什么是“零”?更明确地说,下面的代码会发生什么?void f(int x);void f(string *ps);f(0);               ...
  • lostmouse
  • lostmouse
  • 2001年07月15日 18:27
  • 697

Effective C++ 2e Item3

条款3:尽量用new和delete而不用malloc和freemalloc和free(及其变体)会产生问题的原因在于它们太简单:他们不知道构造函数和析构函数。假设用两种方法给一个包含10个string...
  • lostmouse
  • lostmouse
  • 2001年06月29日 19:39
  • 873

Effective C++ 2e Item42

条款42: 明智地使用私有继承条款35说明,C++将公有继承视为 "是一个" 的关系。它是通过这个例子来证实的:假如某个类层次结构中,Student类从Person类公有继承,为了使某个函数成功调用,...
  • lostmouse
  • lostmouse
  • 2001年08月02日 19:18
  • 649

Effective C++ 2e Item17

 条款17: 在operator=中检查给自己赋值的情况做类似下面的事时,就会发生自己给自己赋值的情况:class X { ... };X a;a = a;                     /...
  • lostmouse
  • lostmouse
  • 2001年07月09日 20:14
  • 634

Effective C++ 2e Item35

继承和面向对象设计很多人认为,继承是面向对象程序设计的全部。这个观点是否正确还有待争论,但本书其它章节的条款数量足以证明,在进行高效的C++程序设计时,还有更多的工具听你调遣,而不仅仅是简单地让一个类...
  • lostmouse
  • lostmouse
  • 2001年07月29日 18:38
  • 585

Effective C++ 2e Item5

内存管理C++中涉及到的内存的管理问题可以归结为两方面:正确地得到它和有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行,那...
  • lostmouse
  • lostmouse
  • 2001年06月30日 13:56
  • 843

Effective C++ 2e Item43

条款43: 明智地使用多继承要看是谁来说,多继承(MI)要么被认为是神来之笔,要么被当成是魔鬼的造物。支持者宣扬说,它是对真实世界问题进行自然模型化所必需的;而批评者争论说,它太慢,难以实现,功能却不...
  • lostmouse
  • lostmouse
  • 2001年08月05日 19:01
  • 672

Effective C++ 2e Item19

 条款19: 分清成员函数,非成员函数和友元函数成员函数和非成员函数最大的区别在于成员函数可以是虚拟的而非成员函数不行。所以,如果有个函数必须进行动态绑定(见条款38),就要采用虚拟函数,而虚拟函数必...
  • lostmouse
  • lostmouse
  • 2001年07月10日 21:21
  • 644

Effective C++ 2e Item22

条款22: 尽量用“传引用”而不用“传值”C语言中,什么都是通过传值来实现的,C++继承了这一传统并将它作为默认方式。除非明确指定,函数的形参总是通过“实参的拷贝”来初始化的,函数的调用者得到的也是函...
  • lostmouse
  • lostmouse
  • 2001年07月13日 20:43
  • 685
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Effective C++ 2e Item47
举报原因:
原因补充:

(最多只允许输入30个字)