views:

651

answers:

3

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? ;)

A: 

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;
}
Dewfy
+6  A: 

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.

Richard Corden
Actually, you can tell. Consider two translation units: A and B. An initializer in B increments a global in A (initialized to 0). main() simply prints the value of the global in A. Will it be 0 or 1?
bdonlan
Is namespace scope distinct from global scope? If I take the globals out of any namespace is it defined in the standard rather than implementation defined?
Joseph Garvin
@bdonlan: Nice example.
Richard Corden
@Joseph: no, the global scope is an outermost namespace scope. When the standard says "namespace scope", it means "not automatics or local statics", it doesn't mean "you wrote `namespace blah {}` around it".
Steve Jessop
In addition, if the initialization occurs lazily then the compiler must generate code that checks to see if it is initialized and perform the initialization. This can wreak havoc when there are multiple threads - this code must be thread safe and c++ does not officially sanction threads - and when it is made thread safe, this thread safe check and possible initialization may be more computationally expensive than expected.
jdkoftinoff
namespace scope is basically anything not in function or class scope. Whether it is defined in the global namespace or in a user-defined namespace under it does not matter.
jalf
Here is my pet-peeve about "global scope": http://stackoverflow.com/questions/423823/whats-your-favorite-programmer-ignorance-pet-peeve/484687#484687 . Anyway, I think you wanted to write 'i2', not 'b' in the last sentence :)
Johannes Schaub - litb
I recently sent an issue report about that paragraph, too: http://groups.google.com/group/comp.std.c++/browse_thread/thread/28cfef85456512c8
Johannes Schaub - litb
A: 

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.

AProgrammer