Boost logo

Boost :

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-02 17:35:34

Rob Stewart-6 wrote
> On May 1, 2013, at 4:33 PM, Anurag Kalia <

> anurag.kalia@

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

So, you are trying to say that optimizing I/O is not really rewarding since
I/O by itself is already orders of magnitude slower? It makes sense to me.
But might there not be cases where we have to store the output not to some
output device, but to a string in memory only?

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

By caching, I meant to say retrieve y,m,d values explicitly as well as some
other properties of the date.

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

To recap, the constructor under discussion looks like:

    date(int a, int b, int c, date_format fmt);

where date_format is an enum type:

    enum date_format { ymd, dmy, mdy };

so that following construction is possible:

    date dt = date(2013, 6, 5, ymd);

All information required is directly in front of the eyes. But thinking more
about it, y-m-d should be the only case possible in the constructor. It is
because date object is streamable. Thus, such construction is possible:

    std::cout << date(4, 5, 2013, dmy);

where output comes out to be "2013-05-04". This seems a little clumsy to me.
Having never seen a precedent like this, my mind is against it a little.
That is the only reason I am antagonist to otherwise completely natural
construction of:

    date natural = day(7) / month(12) / year(2013);

Now, back to your named constructor idiom. Thanks! How true that you learn
something new everyday! I liked it. It actually seems very suitable to my
date class since we are constructing dates also in ordinal date notation
(year, day_of_year) as well as week date notation (year, week_no, weekday).

Again, I have doubts still. First that I have never encountered it in
standard library till now - the library that I use the most. If it exists
somewhere in it or Boost, that would hearten me. Moreover, named constructor
idiom allows construction of objects by the objects themselves. It has
possibility to look ugly. Though, as I write, I think one could always make
them first-class functions which are friends of date class.

Is the latter ok approach? My concerns also extend to performance of
resulting code. But people on internet say that the call is almost always
optimized away.

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at