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-05 19:50:17

On May 5, 2013, at 7:39 PM, Rob Stewart <robertstewart_at_[hidden]> wrote:

> On May 5, 2013, at 7:33 PM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> 
>> On May 5, 2013, at 2:45 PM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:
>> 
>> One possibility (untested) would be to make calculate_year a namespace scope function with the following default implementation:
>> 
>>  year calculate_year(ymd_field_type ymd) {return ymd.year();}
>> 
>> So if the serial date will implicitly convert to ymd_filed_type, then you can say:
>> 
>>  if (ymdTargetDate.month() == calculate_month(date))
>> 
>> And if an implementation thinks they can do better than that then they can overload calculate_xxx(serial_type).  This is very analogous to how we currently handle swap.
>> 
>> Agreed it would be nice to find a better (shorter) name, but one hasn't immediately come to mind.
> 
> get_month?

I thought about that.  And that may be best.  But someone is going to ask:

Why can't I do this:

serial_date x = ...

   set_month(x, dec);

We could just say, sorry, that doesn't make sense.  But the nice thing about calculate_month, or compute_month, is that the reader will intuitively understand that this isn't necessarily a reversible computation.  I.e. get implies returning the value of a field, and it would be nice to not imply that.  On the plus side, get_month is lot easier to type!

Howard