How do I prevent the "static initialization order fiasco"?, C++ FAQ

C++ FAQ / Section 10 / FAQ 10.15

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.15] How do I prevent the "static initialization order fiasco"?

Use the "construct on first use" idiom, which simply means to wrap your static object inside a function.

For example, suppose you have two classes, Fred and Barney. There is a global Fred object called x, and a global Barney object called y. Barney's constructor invokes the goBowling() method on the x object. The file x.cpp defines the x object:

// File x.cpp
#include "Fred.h"
Fred x;

The file y.cpp defines the y object:

// File y.cpp
#include "Barney.h"
Barney y;

For completeness the Barney constructor might look something like this:

// File Barney.cpp
#include "Barney.h"

Barney::Barney()
{
  ...
  x.goBowling();
  ...
}

As described above, the disaster occurs if y is constructed before x, which happens 50% of the time since they're in different source files.

There are many solutions to this problem, but a very simple and completely portable solution is to replace the global Fred object, x, with a global function, x(), that returns the Fred object by reference.

// File x.cpp

#include "Fred.h"

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

Since static local objects are constructed the first time control flows over their declaration (only), the above new Fred() statement will only happen once: the first time x() is called. Every subsequent call will return the same Fred object (the one pointed to by ans). Then all you do is change your usages of x to x():

// File Barney.cpp
#include "Barney.h"

Barney::Barney()
{
  ...
  x().goBowling();
  ...
}

This is called the Construct On First Use Idiom because it does just that: the global Fred object is constructed on its first use.

The downside of this approach is that the Fred object is never destructed. There is another technique that answers this concern, but it needs to be used with care since it creates the possibility of another (equally nasty) problem.

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