[mwild]

ulongIO.C has the same issue as uintIO.C. Here I would take a static_cast<unsigned>, because conversion operators are only defined for one-word types.

Michael

[mwild]

Henry

I think the init-order problem is much worse:

Almost every class contains in it's implementation file a call to either defineTypeNameAndDebug which calls ::Foam::debug::debugSwitch, or it calls that function directly. Other candidates are ::Foam::debug::{info,optimisation}Switch. All of them call (indirectly) ::Foam::debug::switchSet, which in turn calls ::Foam::debug::controlDict, resulting in ::Foam::dotFoam being called, resulting in the same problem as discussed in above posts.

I think you agree that moving all these static initializers into global.Cver is not an option, especially as it would make it impossible to add a new library later on, as that would require a change to global.Cver.

I see these options:

1. Make the XXX::null members use "initialization on first use"
2. Change dotFoam such that it doesn't ever receive al XXX::null instance (by e.g. first checking whether a environment variable exists using Foam::env before calling Foam::getEnv)
3. Don't return XXX:null in any of the functions called by dotFoam

IMHO, none of the options is very appealing...

Michael

[henry]

The ulong issue is now fixed in 1.5.x, thanks for the suggestion.

I will think about the debug switch initialization and get back to you.

H

[mwild]

I don't suppose it would be an option to get rid of all the static variables and replace them with "init on first use"? Probably would introduce quite some overhead, can't be inlined and Info() << "Hello\n" is just dead ugly

[henry]

It's an option but not a good option. I need time to think about it and play with some alternatives.

H

[henry]

Is your original proposed change to ::Foam::dotFoam sufficient to resolve the global construction order problems you are seeing? If so at this point I think it is the best of the options.

H

[mwild]

It solved it for me in the current configuration. But similar issues might crop up anytime (e.g. compiler version changes etc.) However, I do agree that currently this is the easiest way out. Still I would like to see a more permanent solution to the whole issue...

Michael

[henry]

If there are currently no other global construction order dependencies your solution should be general unless we add further globally constructed entities which depend on the current ones -- we should avoid this.

H

[ma404]

Thanks for every thing