You can’t. Again, the relative order of initialization of non-local static objects defined in different translation units is undefined. There is a reason for this. Determining the “proper” order in which to initialize non-local static objects is hard. Very hard. Unsolvably 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 order.

Fortunately, a small design change eliminates the problem entirely. All that has to be done is to move each non-local static object into its own function, where it’s declared static. These functions return references to the objects they contain. Clients then call the functions instead of referring to the objects. In other words, non-local static objects are replaced with local static objects. (Aficionados of design patterns will recognize this as a common implementation of the Singleton pattern. )

This approach is founded on C++(www.cppentry.com)’s guarantee that local static objects are initialized 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, you’re guaranteed that the references you get back 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 objects.

Here’s the technique applied to both tfs and tempDir:

class FileSystem { ... };  // as before  
FileSystem& tfs()  // this replaces the tfs object; it could be  
{  // static in the FileSystem class  
  static FileSystem fs;  // define and initialize a local static object  
  return fs;  // return a reference to it  
}  
class Directory { ... };  // as before  
Directory::Directory( params ) // as before, except references to tfs are  
{  // now to tfs()  
  ...  
  std::size_t disks = tfs().numDisks();  
  ...  
}  
Directory& tempDir()  // this replaces the tempDir object; it  
{  // could be static in the Directory class  
  static Directory td;  // define/initialize local static object  
  return td;  // return reference to it  
} 

Clients of this modified system program exactly as they used to, except they now refer to tfs() and tempDir() instead of tfs and tempDir. That is, they use functions returning references to objects instead of using the objects themselves.