Re: [boost] [chrono/date] Performance goals and design summary

Subject: Re: [boost] [chrono/date] Performance goals and design summary
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-04 19:08:48

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

> I wrote it like this because this was the cleanest I could manage. The
> comparison between months of different years is clumsy. We do need a
> year_month class for it. If there were one, it would look like:
> 
> for( year_month ym(2013, jul), jan14(2014, jan);
>      ym <= jan14;
>      ym += month(1);
>    )
> {
>    std::cout << date(ym, last);
> }
> 
> Suddenly I understand Howard's desire to include it. And I agree now. it
> just makes the whole syntax easier.

The nice thing about year and month arithmetic on a ym type is that it gets rid of the ambiguous semantics of month and year arithmetic, especially if the month and year arithmetic is removed from the ymd type.  The burden on defining the semantics of month and year arithmetic when days are involved now falls explicitly on the shoulders of the client (just as you demonstrate above). 

> This leads me to my next question, are
> there uses for similar class month_day?

I don't see as strong a case the md type.  It could be a short cut.  I even demonstrate such a use in my 2011 paper:

    month_day jan4 = jan/_4th;

but it isn't as compelling.

>> In your proposal, day arithmetic didn't satisfied the following
>> 
>>   assert((aug/last/2011 - day(1) + day(1)) == aug/last/2011);
> 
> How come it does not? The fact that the 'last' attribute gives us an
> absolute date guarantees it. Am I missing something?

I believe what Vicente was referring to is the meta data that was stored by my 2011 proposal.  Day arithmetic would cause the date to forget that it was constructed with last.  Though it would still compare equal to a date constructed with last as long as the two dates had the same serial value.

Howard