Program size, linking matter, and static this()

[Andrei Alexandrescu]

On 12/16/11 3:43 PM, Steven Schveighoffer wrote:
> On Fri, 16 Dec 2011 15:58:28 -0500, Jonathan M Davis
> <jmdavisProg at gmx.com> wrote:
>
>> On Friday, December 16, 2011 14:44:48 Andrei Alexandrescu wrote:
>
>>> As another matter, there is value in minimizing compulsive work during
>>> library startup. Consider for example this code in std.datetime:
>>>
>>> shared static this()
>>> {
>>> tzset();
>>> _localTime = new immutable(LocalTime)();
>>> }
>>>
>>> This summons the garbage collector right off the bat, thus wiping off
>>> anyone's chance of compiling and linking without a GC - as many people
>>> seem to want to do. And that happens not to programs that import and use
>>> std.datetime, but to program using any part of the standard library that
>>> transitively imports std.datetime, even for the most innocuous uses, and
>>> even if they never, ever use _localtime! That one line essentially locks
>>> out 75% of the standard library to anyone wishing to ever avoid using
>>> the GC.
>>
>> This, on the other hand, is of much greater concern, and is a much better
>> argument for using the ugly casting necessary to get rid of the static
>> constructors, even if the compiler did a fanastic job at cutting out
>> the extra
>> cruft in the binary - though as far as the GC goes, it might not be an
>> issue
>> once CTFE is good enough to create classes at compile time that still
>> exist at
>> runtime. Unfortunately, the necessity of tzset would remain however.
>
> This can be solved with malloc and emplace

Sure you meant static ubyte[__traits(classInstanceSize, T)]
and emplace :o).

Andrei