Program size, linking matter, and static this()

[Martin Nowak]

On Wed, 18 Jan 2012 12:14:07 +0100, Martin Nowak <dawg at dawgfoto.de> wrote:

>> Yes they are. static constructors completely chicken out on them. Not  
>> only is
>> there no real attempt to determine whether the static constructors are
>> actually dependent (which granted, isn't an easy problem), but there is  
>> _zero_
>> support in the language for resolving such circular dependencies.  
>> There's no
>> way to say that they _aren't_ dependent even if you can clearly see  
>> that they
>> aren't. The solution used in Phobos (which won't work in std.datetime  
>> due to
>> the use of immutable and pure) is to create a C module which has the  
>> code from
>> the static constructor and then have a separate module which calls it  
>> in its
>> static constructor.
> Which is a hack because that C function is a compiler wall while the  
> dependency
> persists. Btw. that stdiobase and datebase are obsolete the cycles have  
> vanished.
>
> You will get this only if std.dateparse had a shared static ctor too.
>    Cycle detected between modules with ctors/dtors:
>    std.date -> std.dateparse -> std.date
>    object.Exception at src/rt/minfo.d(309): Aborting!
>
> There is a cleaner hack to solve the issue but I really don't like it.
> It's two DAGs that are iterated one for "shared static this" and
> one for "static this".
>
> ----
> module a;
> import b;
>
> shared static this()
> {
> }
> ----
> module b;
> import a, core.atomic : cas;
>
> shared bool initialized;
> static this()
> {
>      if (!cas(&initialized, false, true)) return;
>      ...
> }
> ----
Forget about it. Immutable initialization shouldn't work from thread local  
ctors.
But hey I found a bug and it already had a number
http://d.puremagic.com/issues/show_bug.cgi?id=4923.