Proposal for custom time string formatting in std.datetime

Jonathan M Davis jmdavisProg at gmx.com
Thu Dec 22 11:32:52 PST 2011


On Thursday, December 22, 2011 10:26:27 Walter Bright wrote:
> PIMPL means you have an opaque pointer to something. It can be a function 
> pointer, or a data pointer. It gets filled in at runtime. It has nothing to
> do with .di files.

Well, I have no idea how you'd do that in this case without hiding SysTime's 
implementation, since it has to call TimeZone's functions and therefore needs 
to know that they exist. They're polymorphic, so the exact type of the 
TimeZone could be unknown and unseen by SysTime, but it has to know about 
TimeZone. And if you hid the function bodies in an effort to make TimeZone's 
usage opaque, then you couldn't inline those functions anymore, and I would 
consider the efficiency of the functions to be more important that trying to 
avoid pulling in the TimeZone class just to avoid a few KB in the executable.

On Thursday, December 22, 2011 10:28:52 Walter Bright wrote:
> The time zone info can be lazily initialized only by those operations that
> need a time zone.

I don't think that that would really buy you anything. SysTime is default-
initialized to use LocalTime, which is a singleton, so it's not like you're 
allocating a new TimeZone every time that you create or use a SysTime. 
Currently, the singleton is initialized by a static constructor, but that's 
going to be changed to be lazily initialized (which should get rid of the 
static constructors and their cost). So, there _is_ still some cost on the 
_first_ SysTime that gets created in the program, but after that, there isn't 
really. And doing a lazy initialization of the TimeZone within the SysTime in 
the case where the programmer does not specify a TimeZone would just increase 
the cost of most of SysTime's functions, since most of them would have to be 
checking whether the TimeZone had been initialized or not. With the singleton, 
such a check only occurs when the SysTime is created. And at some point, the 
singleton will probably be change to use emplace, which will allow it to 
completely avoid the GC heap, which will make the singleton cost that much 
less. So, the cost of the time zone from the perspective of execution speed is 
minimal. It sounds like it's just the fact that using a class increases the 
symbols in the executable that's the problem.

- Jonathan M Davis


More information about the Digitalmars-d mailing list