Program size, linking matter, and static this()

Jonathan M Davis jmdavisProg at gmx.com
Fri Dec 16 15:54:36 PST 2011


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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list