I'm used to thinking of all initialization of globals/static-class-members as happening before the first line of main(). But I recently read somewhere that the standard allows initialization to happen later to "assist with dynamic loading of modules." I could see this being true when dynamic linking: I wouldn't expect a global initialized in a library to be initialized before I dlopen'ed the library. However, within a grouping of statically linked together translation units (my app's direct .o files) I would find this behavior very unintuitive. Does this only happen lazily when dynamically linking or can it happen at any time? (or was what I read just wrong? ;)
Let's review a pseudocode:
In DLL:
static int ItsDllVar = 1;
int EXPORTED_FUNCTION() { return ItsDllVar; }
In application:
static int AppVar1 = 2;
static int AppVar2 = EXPORTED_FUNCTION() + AppVar1;
So according to static initializing AppVar2 gets 1+2=3
Lazy initialization applicable for local static variables (regardless of DLL)
int f()
{
static int local_i = 5;//it get's 5 only after visiting f()
return local_i;
}
The standard has the following in 3.6.2/3:
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.
But o Of course you can never officially tell when the initialization takes place since the initialization will occur before you access the variable! as follows:
// t1.cc
#include <iostream>
int i1 = 0;
int main () {
std::cout << i1 << std::endl
// t2.cc
extern int i1;
int i2 = ++i1;
I can conform that g++ 4.2.4 at least appears to perform the initialization of 'i2' before main.
The problem that one wanted to solve with that rule is the one of dynamic loading. The allowance isn't restricted to dynamic loading and formally could happen for other cases. I don't know an implementation which use it for anything else than dynamic loading.