Initialization of static class variables. Difference between POD and std::string

I have a loooong debugging session behind me! I finally found the reason for the problem and now would like to know, if it is a bug in my code or not standardconformant behavour of the compiler(s) or not a bug at all and just normal behavior:
This simple sample program illustrates the problem. Please use separate header (.h) and code (.cpp) files, because it plays a role in the problem...
I built this program using 3 different compilers/linkers:
Borland compiler and linker included in C++ Builder 6.0
Microsoft compiler and linker included in Visual C++ 6.0
GNU compiler and linker (gcc version 3.4.2 (mingw-special))

The GNU compiler builds the program without any problems, but does never enter the main function in debugging mode and crashes in normal mode (GPF)

The Borland and Microsoft Compiler both generate the following output:
Why is the std::string variable not initialized, whereas the int is correctly set to 2?
In Borland C++ the std::string variable even can be in an undefined state leading to occasional system crashes at startup (the reason for my debugging session...).
The "solution" for the problem is strange in my view: I have to move the definition of the std::string variable from the TCStaticMember.cpp file to the TCStaticMember.h file (the locations to delete/paste are marked with bold comments in the code). With Microsoft I then have to use the -F (Force) linker flag because of duplicate definitions, but everything works as expected then...
Borland even does not complain about that and the output is as expected:
I would really appreciate if someone could answer the question, if me, the compilers, the STL implementers or the standard definers did something wrong...

Thanks in advance...

re: Initialization of static class variables. Difference between POD and std::string

You've hit the Static Initialization Fiasco.
The difference between constant ints and char*'s is that the compiler can put
that '2' in the initialized variable space used by the loader, i.e. there will no
instructions necessary to set that variable to the value 2. Not so with the the
char*, i.e. the linker determines where the string constant is stored in real
memory and the loader has to store that address in your static char* variable.

You can't know which globals are initialized first and when you use a
(presumably) initialized variable which actually hasn't been initialized yet: bingo,
you hit the Static Initialization Fiasco.

There's a way around it: initialize everything in one place and take care that
the entire compilation unit is initialized before main is called. I know it's clumsy
but that's the way it is with linkers who know zilch about C++ ;-)

kind regards,

Jos

re: Initialization of static class variables. Difference between POD and std::string

This is just another example of why you should avoid global variables.

Fior a given source file you are guaranteed that the global variables are initialized in the order that they are declared. Just arrange them so the file compiles.

A good designer will put these guys in an anoymous namespace and access them only by functions in that same source file. Users will be required to call the functions rather than use the variables directly.

The last thing you want is the names of your global variables scattered all over the code (the Static Initialization Fiasco). Should you need to redesign, you will have very large job. By using an accssor function all you need to do is change the function (keeping the prototype the same) and recompiling. The users need only re-link.