From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: suggestions for global constructors
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 28 Jul 1992 20:50:52 GMT

In article <EB.92Jul27103609@ascent.ascent.com> eb@ascent.com (Ed Barton) writes:
>In article <1992Jul21.163223.25728@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>   >>Has anyone come up with any good ways of ensuring that static variables
>   >>are instantiated before they are used?
>
>	   They wont, ever. Because it can't be done. It is equivalent
>   to the halting problem.
>
>I'm afraid I find this position rather silly.  I presume you are
>saying that the compiler or linker would need to decide whether 
>
>	if (f()) g(var);
>
>would actually call g() or not, and of course it can't tell that.  But
>I can't believe that we're stuck with a choice between (a) solving the
>halting problem, or (b) having a language in which nonlocal variables
>of class type are unusable.

	I agree. We;re not stuck with that.

>
>    My copy of ARM says that the initialization of nonlocal static
>objects in a translation unit is done before the first use of any
>function or object defined in that translation unit.  

	And it goes on to say that this can't always be done.

	And gives an example I think from memory with circular
	references just to show that sometimes it *really* cant
	be done.

>Perhaps my copy
>is too old, and for all I know the new ARM might say that you can't
>usefully have nonlocal variables of class type.  I understand how it
>can be problematic to implement this, and I wouldn't be surprised if
>none of the compiler vendors have it right.  But just the same, I
>don't think it's impossible.  

	Yes, in general, it IS impossible.

>What I would expect to happen is the
>following:
>
>	Find all inter-module references, where a function in module A
>	  uses a function or variable in module B.
>	Use a topological sort or something to determine an order for
>	  running the constructors that is consistent with the order of
>	  the inter-module references.
>	If no consistent order is possible, produce an error or warning
>	  at link time.
>
>In other words, I would expect to get an error when the compiler can't
>find a way to satisfy the ordering requirement.  I would not expect
>the compiler to solve the halting problem.

	But in general, you might have dynamic choices being made.
Still, you propose, that IF the solution is statically determinable,
THEN the order should be calculated and implemented.

	It is particularly tricky for arithmetic types, which
are first initialised to 0, THEN dynamically initialised,
and are allowed to use this fact, together with the
requirement that within am module initialisations are done in
order.

>
>    Informally, I would probably regard a solution to the ordering
>problem as adequate if it allows me to put classes that have static
>data members in a library, and to have the library's static data
>members properly initialized before the application's initializations.
>Note that there can be dependencies between different library classes,
>and that I can't tell when writing the library which modules of the
>library will be used by an application.
>
>	   The best solution is to make sure there are no interdependencies.
>   One way to do this is to avoid global variables of external linkage.
>   They have very limited use anyhow.
>
>IMO this is not a solution.  
>The same problem arises with static data
>members in a class.  It even arises with global variables that are not
>of external linkage (i.e., static variables), because the
>initializations for another file may call a function in the first file
>which references a static variable in the first file.  I can't agree
>that static data members of class type are of very limited use.
>
	You are right. I guess if you design to have a nice
heirarchical order you should have some way to
enforce it. This could be part of the module system under consideration
perhaps (nominate modules that must be initialise first).


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++