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