problem with static initilization part two.

[originalfamousjohnsmith]

The problem now is that get init using a dummy namespace, then it later initializaes itself! Quite frustrating.

header:

	namespace
	{
		long nJobInitDummy = SJobInit::init();
	};

	SBaseQueue<SWJob>* baseQueue = 0;
	SThreadPool* threadPool = 0;
	long SJobInit::initStatus = 0;

	long SJobInit::init()
	{
		if(initStatus==0)
		{
			initStatus++;
			baseQueue = new SBaseQueue<SWJob>(1000000);
			threadPool = new SThreadPool;
			dout+"job module inited.";
			dout++;
		}
		return 0;
	}

Seems like it gets inited to what I want then inited ti what's above. Anyone know how to resolve this?

[Paul McKenzie]

The problem now is that get init

You should at the very least put this new thread you started in context (even give a link), so that others reading just this thread know what you're talking about.

Regards,

Paul McKenzie

[kempofighter]

I don't have the slightest idea what your are talking about. Either provide a link to the other thread as Paul Suggested or provide enough details so that people can understand the question without reading the other thread.

[D_Drmmr]

header:

	namespace
	{
		long nJobInitDummy = SJobInit::init();
	};

You have an anonymous namespace in a header file. That means the variable will be local to each compilation unit that include this header.
What are you trying to do?

[originalfamousjohnsmith]

The problem is static initialization of dynamic objects.

The rules for this seem to be:
1. All integral static members get integrated to a value usually zero.
2. Then there is a dynamic initialization sequence, for everything that can't be expressed as as primitive type.
2a. This is all in fixed order WITHIN a particular translation unit. A translation unit is...? It's whatever C++ decides to put into one object file, but that is not easy to determine beforehand.
2b. Between translation units, order is NOT fixed, but arbitrary. The compiler can initialize them in any order they want to.
3. When there is a namespace switch, it forces the compiler to finish the initialization of the previous namespace before moving on to the next one. I think. This is where it's a bit muddled.


Effectively, though, the following code can be included in a header file and it will force the init method to be called IMMEDIATELY when it's included, before dynamic static initialization begins at all (but, I believed, AFTER static static initializtion)

namespace
{
	long nJobInitDummy = SJobInit::init();
};

The problem I think I have now is that it's actually going on before there's ANY static initialization, and this causes problems.

IE I have a counter and it starts off as zero, then I init something and the counter gets used a few times, then it gets INITIALIZED and set back to zero.

to make it clearer, the process is like this:
1. compiler reads my header
2. compiler picks up definition of variable
3. more stuff
4. namespace initializer called, variable initialized
5. variable is used a while
6. variable gets INITIALIZED in its definition, resetting it to zero

The other thread will only muddy the waters because it's a little different case, but I will try to post a better code example later if I don't figure it out. I know what's going on but expressing it is hard and it probably takes a bonafide C++ expert/lawyer to even understand the problem is let alone help solve it.

[kempofighter]

Yeah, I'd need to see a more complete example that demonstrates the problem. I've never seen that kind of a technique before. The reason for that is as you have already stated. You don't want to make your design too dependent on the order of header inclusions and static variable initialization. You should be able to construct your objects and initialize your variables in any order without worrying about the language rules or differences in compiler implementations. Some compiler writers occasionally get things wrong. Compilers aren't perfect anyway. You need to base your design on the things that you can control and easily explain to another colleague.

[originalfamousjohnsmith]

Yeah, I'd need to see a more complete example that demonstrates the problem. I've never seen that kind of a technique before. The reason for that is as you have already stated. You don't want to make your design too dependent on the order of header inclusions and static variable initialization. You should be able to construct your objects and initialize your variables in any order without worrying about the language rules or differences in compiler implementations. Some compiler writers occasionally get things wrong. Compilers aren't perfect anyway. You need to base your design on the things that you can control and easily explain to another colleague.

Well, the point is to do it in a way order won't matter, that won't require any overhead, and doesn't require making every single variable use a lock and a guard variable.

Turns out there is no way to stop it from initializing it, no matter what. But, what you can do is have its definition initialize it to itself. Then you can use the anon namespace trick to initialize it at definition time without worry.