Proposal for custom time string formatting in std.datetime

[Walter Bright]

On 12/22/2011 11:32 AM, Jonathan M Davis wrote:
> 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,

Why not hide it?


> 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

Why is the efficiency of those functions important? I cannot think of an 
application that needs high performance timezone calculations. (Benchmark timing 
code does not need timezones.)


 > that trying to
 > avoid pulling in the TimeZone class just to avoid a few KB in the executable.

Kb in the executable does negatively impact performance.

The issue with something being only a few Kb is that when everyone thinks that, 
we wind up with a 1Mb "hello world" program.


> 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.

This conflates performance with allocated memory consumption and with static 
memory consumption.

I am talking about minimizing the executable file size on disk.