Order of initialization

Question

My question pertains to the order of initialization of global objects. It is discussed to some extent here: C++: When (and how) are C++ Global Static Constructors Called?

What I would like to know is, how is it guaranteed that some system library objects (can't think of an example though) are initialized before they are used in application? (I know the solution is to wrap such object in a function, but I want to understand how it is dealt in compilers today)

This is also discussed in the book "linkers and loaders" by John Levine, while talking about .init and .finit sections, but the current state of art is not clear.

Answer 1

An example would be cout.

The compiler doesn't really guarantee that those objects are built before they are used. Take this code:

struct Foo
{

    Foo();
}foo;

#include <iostream>

Foo::Foo()
{
    std::cout << "Hello World";
}

int main() {}

It segfaults because the foo object gets built before cout. When it tries to use cout, bad things happen.

Basically, all the global objects will get code inserted to construct them which runs before main. Once you are in main you are safe, all objects are built. Before that it depends on the order in which they are defined. That's why I can break it by including iostream after declaring the foo global.

Answer 2

Compiler attributes can be used:

In Standard C++, objects defined at namespace scope are guaranteed to be initialized in an order in strict accordance with that of their definitions in a given translation unit. No guarantee is made for initializations across translation units. However, GNU C++ allows users to control the order of initialization of objects defined at namespace scope with the init_priority attribute by specifying a relative priority, a constant integral expression currently bounded between 101 and 65535 inclusive. Lower numbers indicate a higher priority.

Some_Class  A  __attribute__ ((init_priority (2000)));
Some_Class  B  __attribute__ ((init_priority (543)));

I presume under 101 is reserved for the implementation, for things like cout.

http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes

Answer 3

There are a few approaches to make sure global variables are initialized prior to their use. However, these tend to be platform specific and the details differ between system. A typical example of global objects which should be initialized before any user code, including global variable initialization, is run are the global stream objects, in particular std::cout. There are three approaches I have played with to make sure that std::cout is initialized early:

1. The standard library already defines std::ios_base::Init which counts how often it was constructed. By having a static std::ios_base::Init _Init; in the header <iostream> the global stream objects can be initialed using placement new when the counter is changed from 0 to 1 and explicitly destroyed when the counter changes from 1 to 0 during destruction. To avoid double initialization the definition of std::cout would just reserve the necessary space using e.g. char std::cout[sizeof(_Standard_output_stream)];. This approach can break if user code defines objects prior to including <iostream>.
2. When loading shared libraries some initialization code is run before the objects in the shared library become available (likewise some destruction code when unloading a shared library). By putting the corresponding objects into a shared library the initialization code can be run before the object can be accessed. The main drawback is that this requires the use of shared libraries which isn't always desirable.
3. The linker is effectively building the list of initializations. On some systems it is guaranteed that the order in which the various object files are constructed is the reverse order of the object files being seen. That is, placing e.g. std::cout into the last object file in the last [C++] library causes this object to be initialized before other objects. Since users have control over the link line this isn't necessarily working.

The safest approach on this list is to put the objects into a shared library. The best approach is probably to avoid the problem by accessing the global object through a function. All the approaches require some extra work if threads can be started before the construction takes place. In addition, I'm sure there are platform specific approaches which deal with this. The general observation is that global objects are evil: try not to use them!