Program size, linking matter, and static this()

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Dec 16 16:47:02 PST 2011


On 12/16/11 5:54 PM, Jonathan M Davis wrote:
> On Friday, December 16, 2011 16:58:51 Andrei Alexandrescu wrote:
>> On 12/16/11 2:58 PM, Jonathan M Davis wrote:
>>> Unfortunately, the necessity of tzset would remain however.
>>
>> Why? From
>> http://pubs.opengroup.org/onlinepubs/007904875/functions/tzset.html:
>>
>>
>>
"The tzset() function shall use the value of the environment variable TZ
>> to set time conversion information used by ctime(), localtime(),
>> mktime(), and strftime(). If TZ is absent from the environment,
>> implementation-defined default timezone information shall be
>> used."
>>
>> I'd expect a good standard library implementation for D would call
>> tzset() once per process instance, lazily, inside the wrapper
>> functions for the four functions above. Alternatively, people could
>> call the stdc.* versions and expect tzet() to _not_ having been
>> called.
>>
>> That strikes the right balance between convenience, flexibility,
>> and efficiency.
>
> I mean that if CTFE was advanced enough that I could do
>
> immutable _localTime = new LocalTime();
>
> then I could eliminate the shared static constructor for UTC
> completely, but the tzset for LocalTime would still be required. It
> _should_ be run once per process, and it's currently in a shared
> static constructor, so that's what it does. It's just not currently
> lazy. Regardless, my point was that even if CTFE were that advanced,
> the static constructor would still be required. If it's changed so
> that it's lazily loaded, then it can be moved out of the static
> constructor, but the CTFE solution wouldn't be enough.
>
> I'll look at what it would take to get rid of the static constructors
> and make the singletons load lazily, but it will require subverting
> the type system, since it's going to have to break both immutable and
> pure to be loaded lazily.

I think it's all a matter of terminology. Calling tzset during module
initialization is not "required", doing it otherwise is not
"impossible", and the standard library does not have to always "play it
nice". :o)

One more thing - could you take the time to explain why you believe 
calling tzset() compulsively is needed?


Thanks,

Andrei


More information about the Digitalmars-d mailing list