Initialization Sequence of Global Varaibles

[Cheng Mo]

I know global varaibles should always be avoided. I asked this question
just for deep insight about C++.

If global variables are distributed among different source code files,
what's the initialziation sequence of these varaibles. Say,
Foo g_fooMain in main.cpp;
Foo g_hello in hello.cpp;
Foo g_bye in bye.cpp;
and main.cpp has code
#include "hello.h"
#include "bye.h"

Does C++ defines the sequence? or it is compiler-dependent?

Thanks.

[Sumit Rajan]

Cheng Mo wrote:

I know global varaibles should always be avoided. I asked this question
just for deep insight about C++.

If global variables are distributed among different source code files,
what's the initialziation sequence of these varaibles. Say,
Foo g_fooMain in main.cpp;
Foo g_hello in hello.cpp;
Foo g_bye in bye.cpp;
and main.cpp has code
#include "hello.h"
#include "bye.h"

Does C++ defines the sequence? or it is compiler-dependent?

There is no guaranteed order of initialization of global variables in
different translation units. Within a translation unit, global variables
are initialized in their order of definition.

--
Sumit Rajan <su*********@gmail.com>

[Gianni Mariani]

Sumit Rajan wrote:

Cheng Mo wrote:

I know global varaibles should always be avoided. I asked this
question just for deep insight about C++.

If global variables are distributed among different source code files,
what's the initialziation sequence of these varaibles. Say,
Foo g_fooMain in main.cpp;
Foo g_hello in hello.cpp;
Foo g_bye in bye.cpp;
and main.cpp has code
#include "hello.h"
#include "bye.h"

Does C++ defines the sequence? or it is compiler-dependent?

There is no guaranteed order of initialization of global variables in
different translation units. Within a translation unit, global variables
are initialized in their order of definition.

Exactly, if you require a sequence, you can enforce it using static
local variables - e.g.

struct foo
{

static foo & Get()
{
static foo local_static;
return local_static;
}
};
void func()
{
foo & x = foo::Get();

// guarenteed that x refers to a constructed foo object
}

.... note that there may be problems with thread safety in some
implementations. gcc 4.0 will have a fix for this, I'm not sure about
VC++ 2005 though.

[DaKoadMunky]

> note that there may be problems with thread safety in some

implementations. gcc 4.0 will have a fix for this, I'm not sure about
VC++ 2005 though.

Does the standard require it to be thread safe?

If not then making it thread safe is really not a fix, it is just a courtesy.

Will the thread safety of such a construct on gcc 4.0 be optional so that one
does not pay for the cost of unnecessary synchronization for single-threaded
programs?

[Gianni Mariani]

DaKoadMunky wrote:

note that there may be problems with thread safety in some
implementations. gcc 4.0 will have a fix for this, I'm not sure about
VC++ 2005 though.

Does the standard require it to be thread safe?

If not then making it thread safe is really not a fix, it is just a courtesy.

Some people will ague that the standard mentions nothing about threads
and hence it is up to the programmer to make things thread safe.

Some will argue that due to the lack of mentioning anything about
threads, the compiler is required to make certain operations thread safe
if the compiler has any extensions that allow threads.

IMHO, the precedent is that many of the standard C++ types are
implemented in a thread safe way today when they were not in the past.
(e.g. std::string was not thread safe in gcc 2.96 but it has been since
gcc 3.0)

The standard is quite explicit that local static variables must be
constructed once. If your compiler allows any extension that enables
threads, then the compiler must generate code that conforms to the
standard (hence thread safe construction of local static variables).

Will the thread safety of such a construct on gcc 4.0 be optional so that one
does not pay for the cost of unnecessary synchronization for single-threaded
programs?

The gcc-4.0 changes (http://gcc.gnu.org/gcc-4.0/changes.html) says :

- The compiler now uses the library interface specified by
the C++ ABI for thread-safe initialization of function-scope
static variables. Most users should leave this alone, but
embedded programmers may want to disable this by specifying
-fno-threadsafe-statics for a small savings in code size.

It seems that -fno-threadsafe-statics will revert to the old (IMHO buggy
behaviour if you use threads).