global/local static object lifetimes

[hendrixj]

I need to clarify my understanding of the lifetime of certain static objects.
Consider the following file, Experiment.h :

namespace mine
{

    static int persist_ns;

    class Experiment {
        static int persist_Experiment;
        ...
    }
}

Further suppose that this file is *not* included by the file that defines main().

If this is compiled into a program, mine::persist_ns is created before the main() is entered. (Correct?)

Is persist_Experiment also a "global static"; i.e., created before main is executed?

My "C++ in a nutshell" says, "Local static objects are constructed when the execution reaches the object's declaration."
I'm thinking that this refers to a case like this:

int fun() {
   static int my_static_int;
   ...

In this case, my_static_int is created the first time fun() is called. Correct?

[jonnin]

the class static is the same as a global static I think, since a static in a class seems to be shared amongst all class instances (or, maybe I just set mine up this way?). So whenever they are created, it is at the same time, the global scope, which is probably before main but I do not know if that is true across all platforms.

The function one is created the first time the function is called, as you said, but it is not created on the normal function call variable area (usually, just the function call stack is used or is that only windows? ) but is created in the same area globals are.

I am not 100% sure how much of where a variable is stored is set in stone and how much of it just happens to be similar across platforms just due to it being a good approach.

[Danny]

It's more complicated than that. First, you need to define what you mean by "created". Objects with static storage duration (globals, namespace scope and class members which are declared static) undergo two phases of construction: first they are statically initialized which in simple words means: zero initialized. Next, they undergo dynamic initialization during which the initializers (constructors, assuming we're dealing with class objects) are invoked. So you could accidentally access a half-baked object which has undergone the first phase but not the second phase. The only way to guarantee that your objects are fully-constructed before you access them from a different translation unit is to wrap each such object in a function. Alternatively, make them global and move them to the translation unit which declares main (but again, other translation unit might access them prematurely).
You can find all the details here: http://www.informit.com/guides/conte...lus&seqNum=212
As far as static class members of pod types are concerned: they are pretty much identical to global objects in the sense that they can be visible from other translation units.

[vijayan]

well, the fundamental question is not POD or non-POD, but weather an object with static static storage duration requires dynamic initialization. for example:

#include <iostream>

extern int first ;

int second = ( ( std::cout << "initializing second with first(" << first << ")\n" ), first ) ;

int first = ( ( std::cout << "initializing first\n" ), 20 ) ;

int main()
{
   std::cout << "first: " << first << "\tsecond: " << second << '\n' ;
}

second will be initialized before first (in order of definition), with the uninitialized (zero initialized) value of first.

another resource dealing with initialization order across translation units: http://www.parashift.com/c++-faq-lit...html#faq-10.12

[Danny]

you're right, dynamic initialization may also apply to POD types, e.g., those that are initialized with a non-constant expression that the compiler can't evaluate.
The relative order of initialization is guaranteed within the translation unit but there's no such guarantee across translation units.