Dynamic initialization phase of static variables

Question

The standard specifically states that dynamic initialization of static duration variables (namespace scope and class static members) does not have to occur before main is executed: "It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main." IS 3.6.2(3) Is it not how dynamic initialization is [always?] implemented? What better/easier way to guarantee that the objects are initialized before use?

Answer 1

The answer to your question is in the next sentence (in 3.6.2 of ISO/IEC 14882-2003) after the one you've quoted.

It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function or object defined in the same translation unit as the object to be initialized.

Obviously to make sure that some variable X is initialized you just have to use in function main (directly or indirectly) any function or variable defined in the same translation unit as the variable X (e.g. if you directly or indirectly use X in function main then you may be sure it is already initialized).

EDIT:

If in addition to the assurance that the variable you use is already initialized (it always is - as guaranteed by the standard text quoted above) you also want to know why standard contains the provision that initialization may be delayed after main execution start.

I mean if the question is also: Why not just demand that all initialization is performed before main starts?

Well it is definitely not about dynamically linked libraries - no problem to initialize all their objects before starting main. Also it is not about dynamically loaded libraries (LoadLibrary/dlopen) - they are not within a realm of C++ standard obviously (they are not subject to One Definition Rule for example and in general they may even be not C++).

In theory this provision allows lazy initialization to avoid unnecessary runtime overhead - e.g. unless you actually use some function or object from a specific translation unit (C++ source file) you don't have to do its runtime initialization. But it is unlikely that any implementation actually do lazy initialization in runtime - multi-threading synchronization is challenging for this kind of initialization and is itself a runtime overhead.

BUT what every single implementation actually do is linking only those modules (translation units) that are actually used. So even if you link with some static library that contain some dynamically initialized object (maybe with side effect - like file creation or user interaction) but don't use anything from the same translation unit - implementation is not obliged to run initialization of this object at all. So this provision allows avoiding inclusion of any unused translation units in final executable - even if they are formally part of the program.

Answer 2

I believe the intention here is to allow dynamic load libraries.

Static variables defined in the libraries are not guaranteed to be initialized before main, but must happen before anything in the specific library is used.