Initialize global variable before any other global variables

[jubelbrus]

I need to initiate a global variable to a class before the
initialization of any other global variable.
The problem is that when I link the application with a dll, some or
all global variables in the dll is initialized before mine.

Is there a way to ensure that my global variable is initialized before
any other?

Take a simple class

class test {

}

#pragma init_seg(compiler)
test t;

According to msdn, "Objects in this group are constructed first".
That's the "compiler" group.

I'm using Microsoft Visual Studio.net 2005/VC++ on Windows XP

 

[Victor Bazarov]

I need to initiate a global variable to a class before the
initialization of any other global variable.
The problem is that when I link the application with a dll, some or
all global variables in the dll is initialized before mine.

Is there a way to ensure that my global variable is initialized before
any other?

Well... Search the FAQ for "fiasco". Draw your own conclusions.

Take a simple class

class test {

}

#pragma init_seg(compiler)
test t;

According to msdn, "Objects in this group are constructed first".
That's the "compiler" group.

There is no such thing in standard C++ language. It's something that
most likely unique to that compiler.

I'm using Microsoft Visual Studio.net 2005/VC++ on Windows XP

Then you need to ask in the newsgroup dedicated to that compiler.

V

 

[James Kanze]

I need to initiate a global variable to a class before the
initialization of any other global variable.

Why? Check out the singleton idiom. It can't guarantee this,
but it usually guarantees enough---that the variable is
initialized before it is used.

 

[JohnQ]

I need to initiate a global variable to a class before the
initialization of any other global variable.

"Why? Check out the singleton idiom. It can't guarantee this,
but it usually guarantees enough---that the variable is
initialized before it is used."

The trickier issue is making sure it sticks around long enough after main
because chances are, that if it needs to be used by other globals before
main that it will be used after main also.

John

 

[James Kanze]

The trickier issue is making sure it sticks around long enough
after main because chances are, that if it needs to be used by
other globals before main that it will be used after main
also.

In practice, that's less often a problem; destructors generally
don't need nearly as much as constructors. And in the classical
Singleton idiom (in the GoF), the singleton object is never
destructed anyway. (My generic singleton offers the choice, but
defaults to never destructing, since that is the prefered
behavior 99% of the time.)

 

[JohnQ]

The trickier issue is making sure it sticks around long enough
after main because chances are, that if it needs to be used by
other globals before main that it will be used after main
also.

"In practice, that's less often a problem; destructors generally
don't need nearly as much as constructors. And in the classical
Singleton idiom (in the GoF), the singleton object is never
destructed anyway. (My generic singleton offers the choice, but
defaults to never destructing, since that is the prefered
behavior 99% of the time.)"

Preferred by you, that is. I consider that to be a non-solution (loose
ends). I like knowing that every object that is constructed, will be
destructed. I never liked the idea of allocating memory and never
deallocating it (letting the system clean up at program termination) either.
Orderly/graceful shut down design is as important as startup, IMO. The
language is lacking probably in regards to initialization and termination,
but that means one must (should, IMO) devise ways of dealing with the issues
rather than ignoring them. It's a case of "it works" vs. being
well-designed/architected/engineered. The GoF pattern is obviously only half
done.

John