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

Subject: Re: [boost] [chrono/date] Performance goals and design summary
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 12:45:54

Le 04/05/13 17:02, Howard Hinnant a écrit :
> On May 4, 2013, at 9:56 AM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:
>
>> 5. I'm not sure the date YMD class doesn't include meta data (Howard
>>    could you clarify your point here)
> I've left that question open.  However if I had to make a decision today, I would say definitely not.  That aspect of my 2011 paper was almost universally disliked.  There are more ways to explore for getting the same or similar functionality.  Or simply dropping that functionality is a consideration.
>
>> * *Do we need to make the separation between absolute and relative
>>    dates?* IMO, yes. While relative dates are powerful they incur on
>>    unwanted overhead when absolute dates are needed.
> I can guess what you mean by relative and absolute dates, but I'd rather not.  Can you briefly describe what these types of dates are?
>
>
The date class of your proposal is what I call a relative date, as it 
contains meta-data as last day of the month, 2nd sunday of month, ...
Arithmetic on relative dates is often quite powerful. We could call them 
contextual dates or a better name if you find it.
What I call an absolute date is a date that has no meta-data, it defines 
exactly a date without a context.

28/feb/2013 is an absolute date while last/feb/2013 is a 
relative/contextual date.

Taking one of examples in your original proposal

// Print Feb. 28 for each year in the decade
for (date d = feb/day(28)/2010, e = feb/day(28)/2020; d != e; d += years(1))
     std::cout << d << '\n';

// Print the last day in  Feb. for each year in the decade
for (*rel_**date*  d = feb/*last*/2010,*date*  e = feb/*last*/2020; d != e; d += years(1))
     std::cout << d << '\n';

rel_date implicitly converts to date of course, so that the comparison 
works as expected, the opposite not been true.

So the following is valid

   date dt = feb/last/2020;

It is also true that this implicit conversion could result in surprising 
behavior (as usual)

// Print Feb. 28 and notthe last day in  Feb. for each year in the decade
for (***date*  d = feb/*last*/2010, e = feb/*last*/2020; d != e; d += years(1))
     std::cout << d << '\n';

Maybe this implicit conversion should be explicit.

In your proposal, day arithmetic didn't satisfied the following

   assert((aug/last/2011 - day(1) + day(1)) == aug/last/2011);

IMO this was because there was only a date class, that needed to store 
the absolute date and the meta-data, and using more meta-data on a 
general date class was not an option. If we have two separated classes, 
the relative_date could contain more meta-data and so be able to satisfy 
the preceding assertion. Of course this is only a possibility and we 
don't need to have a design that preserves the assertion.

There is last point about relative/contextual dates. How relative dates 
compare. IMO, the meta-data should be part of the comparison.

IMO, a date library should provide both, with no additional performance 
cost when working with absolute dates.

Best,
Vicente