Static initialization order

[Justin Johansson]

Ali Çehreli wrote:
> Justin Johansson wrote:
>  > Walter Bright wrote:
>  >> Justin Johansson wrote:
>  >>> May I ask, what are the best solutions for C++ (my current
>  >>> dilemma) and what steps will be taken in D2 to zap it.
>  >>
>  >> Within a module, static initialization is done in lexical order.
>  >>
>  >> Across modules, static initialization is performed so that imported
>  >> modules are initialized before the importer.
>  >>
>  >> This is true in D1 as well as D2.
>  >
>  > Thanks for the clarification for both D1 and D2.  Certainly D's approach
>  > beats the hit-and-miss approach in C++.
> 
> That's unfortunate and has been many causes of bugs for C++ programs.
> 
> C++ follows C's model of separate compilation. The C++ compiler never 
> sees more than one translation unit (a source file after all 
> preprocessor magic applied to it) at a time.
> 
> The best C++ could do was to define the order in that single translation 
> unit; and that is the same order as D's.
> 
> Ali

Thanks for your comment, Ali.

Yes, well, that unfortunately is what I'm doing in my C++ project ..
putting implementation of all the static class declarations in one
big file.  It's a bit of a pain because that makes for another file
to maintain rather having the static init source code in the respective
class .cpp file.  On the other hand, at least I can see all the static
inits in one place and that turns out to be a small benefit.

The only other idea, of dubious worth, is to create a "proxy"
initialization class which is parameterized with a init-order
priority attribute.  Concept is that all these proxies would collated
and sorted according to their priority.  Upon entering main() each
static init is fired off in the priority-ordered init order.

D1 isn't completely without its warts though.  When I was trying to
implement this particular project in D1, I had all sorts of circular
reference problems, either compiling or linking code (can't remember
which), to do with static objects and so I still had to resort to
collating some disparate code into a single file.  Like I say, I
cannot remember the full details of the workaround but there was
something on D.help which addressed the issue.

Cheers

Justin