I have a script that uses globals that access eachother. In order to ensure proper order of initialization, i create the instance of the global that is accessed by other globals on demand:

namespace detail
{
CMultiScripts@ __MultiScripts = null;
}

/**
*	Gets the global multi scripts manager.
*/
CMultiScripts@ get_MultiScripts()
{
	if( detail::__MultiScripts is null )
	{
		@detail::__MultiScripts = CMultiScripts();
	}
		
	return @detail::__MultiScripts;
}

However, because i initialize it to null explicitly, the global is initialized to null after my globals have called get_MultiScripts, destroying the first instance.

If i remove the explicit assignment, everything works as expected.

I think this may be a bug, should the compiler remove explicit initialization to null with handles in this case?

I'll investigate this.

I think this particular situation can probably be easily fixed the way you suggested by detecting and removing explicit initialization to null.

As for guaranteeing correct order of initialization of global variables, that is a much trickier matter. To some extent the compiler already tries to reorder the initialization so that a variable that depends on another will be initialized later. However, currently when the access to the other variable is hidden with function calls the compiler is not able to see the dependency. I have on my to-do list an item to try to implement a deep scan of the produced bytecode to verify the dependencies even for these cases, but that is a rather complex implementation and it will probably take a while before I even get to start working on this.

I've changed this in revision 2377, so that now handles explicitly initialized with null in declarations no longer produce any bytecode.

Regards,

Andreas