How do I prevent the "static initialization order fiasco" for my static data members?, C++ FAQ

C++ FAQ / Section 10 / FAQ 10.17

Section 10:

10.1	What's the deal with constructors?
10.2	Is there any difference between `List x;` and `List x();`?
10.3	Can one constructor of a class call another constructor of the same class to initialize the `this` object? Updated!
10.4	Is the default constructor for `Fred` always `Fred::Fred()`?
10.5	Which constructor gets called when I create an array of `Fred` objects?
10.6	Should my constructors use "initialization lists" or "assignment"?
10.7	Should you use the `this` pointer in the constructor?
10.8	What is the "Named Constructor Idiom"?
10.9	Does return-by-value mean extra copies and extra overhead?
10.10	Does the compiler optimize returning a local variable by value?
10.11	Why can't I initialize my `static` member data in my constructor's initialization list?
10.12	Why are classes with `static` data members getting linker errors?
10.13	Can I add `=` initializer`;` to the declaration of a class-scope `static` `const` data member?
10.14	What's the "`static` initialization order fiasco"?
10.15	How do I prevent the "`static` initialization order fiasco"?
10.16	Why doesn't the construct-on-first-use idiom use a static object instead of a static pointer?
10.17	How do I prevent the "`static` initialization order fiasco" for my `static` data members?
10.18	Do I need to worry about the "`static` initialization order fiasco" for variables of built-in/intrinsic types?
10.19	How can I handle a constructor that fails?
10.20	What is the "Named Parameter Idiom"?
10.21	Why am I getting an error after declaring a `Foo` object via `Foo x(Bar())`?
10.22	What is the purpose of the `explicit` keyword?

[10.17] How do I prevent the "static initialization order fiasco" for my static data members?

Just use the same technique just described, but this time use a static member function rather than a global function.

Suppose you have a class X that has a static Fred object:

// File X.h

class X {
public:
  ...

private:
  static Fred x_;
};

Naturally this static member is initialized separately:

// File X.cpp

#include "X.h"

Fred X::x_;

Naturally also the Fred object will be used in one or more of X's methods:

void X::someMethod()
{
  x_.goBowling();
}

But now the "disaster scenario" is if someone somewhere somehow calls this method before the Fred object gets constructed. For example, if someone else creates a static X object and invokes its someMethod() method during static initialization, then you're at the mercy of the compiler as to whether the compiler will construct X::x_ before or after the someMethod() is called. (Note that the ANSI/ISO C++ committee is working on this problem, but compilers aren't yet generally available that handle these changes; watch this space for an update in the future.)

In any event, it's always portable and safe to change the X::x_ static data member into a static member function:

// File X.h

class X {
public:
  ...

private:
  static Fred& x();
};

Naturally this static member is initialized separately:

// File X.cpp

#include "X.h"

Fred& X::x()
{
  static Fred* ans = new Fred();
  return *ans;
}

Then you simply change any usages of x_ to x():

void X::someMethod()
{
  x().goBowling();
}

If you're super performance sensitive and you're concerned about the overhead of an extra function call on each invocation of X::someMethod() you can set up a static Fred& instead. As you recall, static local are only initialized once (the first time control flows over their declaration), so this will call X::x() only once: the first time X::someMethod() is called:

void X::someMethod()
{
  static Fred& x = X::x();
  x.goBowling();
}

Note: The static initialization order fiasco can also, in some cases, apply to built-in/intrinsic types.