problem with static initilization part two.
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7

Thread: problem with static initilization part two.

  1. #1

    problem with static initilization part two.

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

    header:
    Code:
    	namespace
    	{
    		long nJobInitDummy = SJobInit::init();
    	};
    Code:
    	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?

  2. #2
    Join Date
    Apr 1999
    Posts
    27,434

    Re: problem with static initilization part two.

    Quote Originally Posted by originalfamousjohnsmith View Post
    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

  3. #3
    Join Date
    Aug 2005
    Location
    San Diego, CA
    Posts
    1,054

    Lightbulb Re: problem with static initilization part two.

    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.

  4. #4
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,014

    Re: problem with static initilization part two.

    Quote Originally Posted by originalfamousjohnsmith View Post
    header:
    Code:
    	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?
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  5. #5

    Re: problem with static initilization part two.

    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)
    Code:
    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.
    Last edited by originalfamousjohnsmith; November 13th, 2009 at 04:00 PM.

  6. #6
    Join Date
    Aug 2005
    Location
    San Diego, CA
    Posts
    1,054

    Lightbulb Re: problem with static initilization part two.

    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.

  7. #7

    Re: problem with static initilization part two.

    Quote Originally Posted by kempofighter View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center