Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-02 08:37:38

On May 1, 2013, at 4:33 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:

> Vicente Botet wrote
>> 
>> Anurag Kalia wrote
>> 
> As I have already mentioned, an application requiring absolute
> performance from date class would use its operations. And nothing can beat a serial representation at comparisons, assignments and day/week arithmetic.
> 
> ymd represntations, OTOH, optimize I/O. And an application requiring such optimization can simply employ a representation like:
> struct date
> {
>    int y, m, d;
> };
> 
> which serves their purpose well enough.

Optimizing I/O, which is a relatively slow process anyway, is possibly misguided. The YMD format could be extracted from the serial format to reuse, but I imagine a given object being formatted for I/O in a single function call, Ã  la strftime(), rather than in a series of formatting calls. Still, even the latter is possible with a formatter object which extracts the YMD values once and applies various formatting operations, as desired.

> For the vast majority however,
> serial representation is good enough. After caching as you know, performance nears ymd in these scenarios too.

Caching suggests larger objects and, possibly lower locality of reference.

>>> I genuinely am curious why adding that fourth parameter might be a bad design.
>> Well, this is a taste question. I will comeback to your functional format later.
> 
> I myself have dropped this constructor. After all, it is not difficult for users to check documentation for the order of the date parameters. It just
> eats up the performance anyway, even if it is just a switch statement.

I'm not sure of the context here, but relying on documentation to ensure correct argument order will only frustrate users, because it is error prone. The Named Constructor Idiom is beneficial in such cases.

___
Rob

(Sent from my portable computation engine)