?? ei47.htm
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd">
<HTML LANG="EN">
<HEAD>
<title>Effective C++, 2E | Item 47: Ensure that non-local static objects are initialized before they're used</TITLE>
<LINK REL=STYLESHEET HREF=../INTRO/ECMEC.CSS>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/COOKIE.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">var imagemax = 0; setCurrentMax(0);</SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/DINGBATS.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">
var dingbase = "EI47_DIR.HTM";
var dingtext = "Item E47, P";
if (self == top) {
top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- SectionName="E47: Initialization of non-local static objects" -->
<A NAME="8299"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI46_FR.HTM" TARGET="_top">Item 46: Prefer compile-time and link-time errors to runtime errors.</A> <BR> Continue to <A HREF="./EI48_FR.HTM" TARGET="_top">Item 48: Pay attention to compiler warnings.</A></FONT></DIV>
<P><A NAME="dingp1"></A><FONT ID="eititle">Item 47: Ensure that non-local static objects are initialized before they're used.</FONT><SCRIPT>create_link(1);</SCRIPT>
</P>
<A NAME="8300"></A>
<P><A NAME="dingp2"></A>
You're an adult now, so you don't need me to tell you it's foolhardy to use an object before it's been initialized. In fact, the whole notion may <A NAME="p220"></A>strike you as absurd; constructors make sure objects are initialized when they're created, <I>n'est-ce pas</I>?<SCRIPT>create_link(2);</SCRIPT>
</P>
<A NAME="8303"></A>
<P><A NAME="dingp3"></A>
Well, yes and no. Within a particular translation unit (i.e., source file), everything works fine, but things get trickier when the initialization of an object in one translation unit depends on the value of another object in a different translation unit <i>and</i> that second object itself requires <NOBR>initialization.<SCRIPT>create_link(3);</SCRIPT>
</NOBR></P>
<A NAME="30382"></A>
<P><A NAME="dingp4"></A>
For example, suppose you've authored a library offering an abstraction of a file system, possibly including such capabilities as making files on the Internet look like they're local. Since your library makes the world look like a single file system, you might create a special object, <CODE>theFileSystem</CODE>, within your library's namespace (see <A HREF="./EI28_FR.HTM#6429" TARGET="_top">Item 28</A>) for clients to use whenever they need to interact with the file system abstraction your library <NOBR>provides:<SCRIPT>create_link(4);</SCRIPT>
</NOBR></P>
<A NAME="30547"></A>
<UL><PRE>
class FileSystem { ... }; // this class is in your
// library
</PRE>
</UL><A NAME="30587"></A>
<UL><PRE>
FileSystem theFileSystem; // this is the object
// with which library
// clients interact
</PRE>
</UL><A NAME="30588"></A>
<P><A NAME="dingp5"></A>
Because <CODE>theFileSystem</CODE> represents something complicated, it's no surprise that its construction is both nontrivial and essential; use of <CODE>theFileSystem</CODE> before it had been constructed would yield <I>very</I> undefined behavior. (However, consult <A HREF="../MEC/MI17_FR.HTM#41011" TARGET="_top">Item M17</A> for ideas on how the effective initialization of objects like <CODE>theFileSystem</CODE> can safely be <NOBR>delayed.)<SCRIPT>create_link(5);</SCRIPT>
</NOBR></P>
<A NAME="30564"></A>
<P><A NAME="dingp6"></A>
Now suppose some client of your library creates a class for directories in a file system. Naturally, their class uses <CODE>theFileSystem</CODE>:<SCRIPT>create_link(6);</SCRIPT>
</P>
<A NAME="30565"></A>
<UL><PRE>
class Directory { // created by library client
public:
Directory();
...
};
</PRE>
</UL><A NAME="30566"></A>
<UL><PRE>Directory::Directory()
{
<I>create a</I> Directory <I>object by invoking member
functions on</I> theFileSystem;
}
</PRE>
</UL><A NAME="30567"></A>
<P><A NAME="dingp7"></A>
Further suppose this client decides to create a distinguished global <CODE>Directory</CODE> object for temporary <NOBR>files:<SCRIPT>create_link(7);</SCRIPT>
</NOBR></P>
<A NAME="30573"></A>
<UL><PRE>
Directory tempDir; // directory for temporary
// files
</PRE>
</UL><A NAME="30574"></A>
<P><A NAME="dingp8"></A>
<A NAME="p221"></A>Now the problem of initialization order becomes apparent: unless <CODE>theFileSystem</CODE> is initialized before <CODE>tempDir</CODE>, <CODE>tempDir</CODE>'s constructor will attempt to use <CODE>theFileSystem</CODE> before it's been initialized. But <CODE>theFileSystem</CODE> and <CODE>tempDir</CODE> were created by different people at different times in different files. How can you be sure that <CODE>theFileSystem</CODE> will be created before <CODE>tempDir</CODE>?<SCRIPT>create_link(8);</SCRIPT>
</P>
<A NAME="8313"></A>
<P><A NAME="dingp9"></A>
This kind of question arises anytime you have <I>non-local static objects</I> that are defined in different translation units and whose correct behavior is dependent on their being initialized in a particular order. Non-local static objects are objects that <NOBR>are<SCRIPT>create_link(9);</SCRIPT>
</NOBR></P>
<UL><A NAME="24055"></A>
<A NAME="dingp10"></A><LI>defined at global or namespace scope (e.g., <CODE>theFileSystem</CODE> and <CODE>tempDir</CODE>),<SCRIPT>create_link(10);</SCRIPT>
<A NAME="30829"></A>
<A NAME="dingp11"></A><LI>declared <CODE>static</CODE> in a class, or<SCRIPT>create_link(11);</SCRIPT>
<A NAME="24056"></A>
<A NAME="dingp12"></A><LI>defined <CODE>static</CODE> at file scope.<SCRIPT>create_link(12);</SCRIPT>
</UL></P>
<A NAME="195248"></A>
<P><A NAME="dingp13"></A>
Regrettably, there is no shorthand term for "non-local static objects," so you should accustom yourself to this somewhat awkward <NOBR>phrase.<SCRIPT>create_link(13);</SCRIPT>
</NOBR></P>
<A NAME="195249"></A>
<P><A NAME="dingp14"></A>
You do not want the behavior of your software to be dependent on the initialization order of non-local static objects in different translation units, because you have no control over that order. Let me repeat that. <I>You have absolutely no control over the order in which non-local static objects in different translation units are initialized.</I><SCRIPT>create_link(14);</SCRIPT>
</P>
<A NAME="24544"></A>
<P><A NAME="dingp15"></A>
It is reasonable to wonder why this is the <NOBR>case.<SCRIPT>create_link(15);</SCRIPT>
</NOBR></P>
<A NAME="223072"></A>
<P><A NAME="dingp16"></A>
It is the case because determining the "proper" order in which to initialize non-local static objects is hard. Very hard. Halting-Problem hard. In its most general form — with multiple translation units and non-local static objects generated through implicit template instantiations (which may themselves arise via implicit template instantiations) — it's not only impossible to determine the right order of initialization, it's typically not even worth looking for special cases where it is possible to determine the right <NOBR>order.<SCRIPT>create_link(16);</SCRIPT>
</NOBR></P>
<A NAME="24419"></A>
<P><A NAME="dingp17"></A>
In the field of Chaos Theory, there is a principle known as the "Butterfly Effect." This principle asserts that the tiny atmospheric disturbance caused by the beating of a butterfly's wings in one part of the world can lead to profound changes in weather patterns in places far distant. Somewhat more rigorously, it asserts that for some types of systems, minute perturbations in inputs can lead to radical changes in <NOBR>outputs.<SCRIPT>create_link(17);</SCRIPT>
</NOBR></P>
<A NAME="24095"></A>
<P><A NAME="dingp18"></A>
The development of software systems can exhibit a Butterfly Effect of its own. Some systems are highly sensitive to the particulars of their requirements, and small changes in requirements can significantly af<A NAME="p222"></A>fect the ease with which a system can be implemented. For example, <A HREF="./EI29_FR.HTM#6490" TARGET="_top">Item 29</A> describes how changing the specification for an implicit conversion from <CODE>String</CODE>-to-<CODE>char*</CODE> to <CODE>String</CODE>-to-<CODE><I>const</I></CODE>-<CODE>char*</CODE> makes it possible to replace a slow or error-prone function with a fast, safe <NOBR>one.<SCRIPT>create_link(18);</SCRIPT>
</NOBR></P>
<A NAME="24585"></A>
<P><A NAME="dingp19"></A>
The problem of ensuring that non-local static objects are initialized before use is similarly sensitive to the details of what you want to achieve. If, instead of demanding access to non-local static objects, you're willing to settle for access to objects that <I>act</I> like non-local static objects (except for the initialization headaches), the hard problem vanishes. In its stead is left a problem so easy to solve, it's hardly worth calling a problem any <NOBR>longer.<SCRIPT>create_link(19);</SCRIPT>
</NOBR></P>
<A NAME="24581"></A>
<P><A NAME="dingp20"></A>
The technique — sometimes known as the <I>Singleton pattern</I> — is simplicity itself. First, you move each non-local static object into its own function, where you declare it <CODE>static</CODE>. Next, you have the function return a reference to the object it contains. Clients call the function instead of referring to the object. In other words, you replace non-local static objects with objects that are <CODE>static</CODE> inside functions. (See also <A HREF="../MEC/MI26_FR.HTM#5350" TARGET="_top">Item M26</A>.)<SCRIPT>create_link(20);</SCRIPT>
</P>
<A NAME="30738"></A>
<P><A NAME="dingp21"></A>
The basis of this approach is the observation that although C++ says next to nothing about when a non-local static object is initialized, it specifies quite precisely when a static object inside a function (i.e. a <I>local</I> static object) is initialized: it's when the object's definition is first encountered during a call to that function. So if you replace direct accesses to non-local static objects with calls to functions that return references to local static objects inside them, you're guaranteed that the references you get back from the functions will refer to initialized objects. As a bonus, if you never call a function emulating a non-local static object, you never incur the cost of constructing and destructing the object, something that can't be said for true non-local static <NOBR>objects.<SCRIPT>create_link(21);</SCRIPT>
</NOBR></P>
<A NAME="30648"></A>
<P><A NAME="dingp22"></A>
Here's the technique applied to both <CODE>theFileSystem</CODE> and <CODE>tempDir</CODE>:<SCRIPT>create_link(22);</SCRIPT>
</P><A NAME="30650"></A>
<UL><PRE>
class FileSystem { ... }; // same as before
</PRE>
</UL><A NAME="30654"></A>
<UL><PRE>
FileSystem& theFileSystem() // this function replaces
{ // the theFileSystem object
</PRE>
</UL><A NAME="30741"></A>
<UL><PRE>
static FileSystem tfs; // define and initialize
// a local static object
// (tfs = "the file system")
</PRE>
</UL><A NAME="30655"></A>
<UL><PRE>
return tfs; // return a reference to it
}
</PRE>
</UL><A NAME="30659"></A>
<UL><PRE>
class Directory { ... }; // same as before
</PRE>
</UL><A NAME="30752"></A>
<UL><PRE><A NAME="p223"></A>Directory::Directory()
{
<I>same as before, except references to</I> theFileSystem <I>are
replaced by references to</I> theFileSystem<I>();</I>
}
</PRE>
</UL><A NAME="30745"></A>
<UL><PRE>
Directory& tempDir() // this function replaces
{ // the tempDir object
</PRE>
</UL><A NAME="30755"></A>
<UL><PRE>
static Directory td; // define/initialize local
// static object
</PRE>
</UL><A NAME="30794"></A>
<UL><PRE>
return td; // return reference to it
}
</PRE>
</UL><A NAME="30682"></A>
<P><A NAME="dingp23"></A>
Clients of this modified system program exactly as they used to, except they now refer to <CODE>theFileSystem()</CODE> and <CODE>tempDir()</CODE> instead of <CODE>theFileSystem</CODE> and <CODE>tempDir</CODE>. That is, they refer only to functions returning references to those objects, never to the objects <NOBR>themselves.<SCRIPT>create_link(23);</SCRIPT>
</NOBR></P>
<A NAME="24703"></A>
<P><A NAME="dingp24"></A>
The reference-returning functions dictated by this scheme are always simple: define and initialize a local static object on line 1, return it on line 2. That's it. Because they're so simple, you may be tempted to declare them <CODE>inline</CODE>. <A HREF="./EI33_FR.HTM#6729" TARGET="_top">Item 33</A> explains that late-breaking revisions to the C++ language specification make this a perfectly valid implementation strategy, but it also explains why you'll want to confirm your compilers' conformance with this aspect of <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>°</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=cstandard" onMouseOver = "self.status = 'The latest publicly-available version of the C++ standard'; return true" onMouseOut = "self.status = self.defaultStatus" TARGET="_top">the</NOBR> standard</A> before putting it to use. If you try it with a compiler not yet in accord with the relevant parts of the standard, you risk getting multiple copies of both the access function and the static object defined within it. That's enough to make a grown programmer <NOBR>cry.<SCRIPT>create_link(24);</SCRIPT>
</NOBR></P>
<A NAME="8375"></A>
<P><A NAME="dingp25"></A>
Now, there's no magic going on here. For this technique to be effective, it must be possible to come up with a reasonable initialization order for your objects. If you set things up such that object A must be initialized before object B, and you also make A's initialization dependent on B's having already been initialized, you are going to get in trouble, and frankly, you deserve it. If you steer shy of such pathological situations, however, the scheme described in this Item should serve you quite <NOBR>nicely.<SCRIPT>create_link(25);</SCRIPT>
</NOBR></P>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI46_FR.HTM" TARGET="_top">Item 46: Prefer compile-time and link-time errors to runtime errors.</A> <BR> Continue to <A HREF="./EI48_FR.HTM" TARGET="_top">Item 48: Pay attention to compiler warnings.</A></FONT></DIV>
</BODY>
</HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -