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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-03 19:19:52

Le 04/05/13 01:05, Vicente J. Botet Escriba a écrit :
> Le 03/05/13 19:53, Howard Hinnant a écrit :
>> On May 3, 2013, at 1:46 PM, "Vicente J. Botet Escriba" 
>> <vicente.botet_at_[hidden]> wrote:
>>
>>> Howard, I believe I start to understand why you don't want 
>>> day/month/year to validate its input.
>>> I suspect that the rationale is quite simple, you are relaying on 
>>> undefined behavior when the value of these parameters is out of 
>>> range, isn't it?
>> class day
>> {
>>      int d_;
>> public:
>>      constexpr
>>      explicit
>>      day(int d) noexcept
>>          : d_(d)
>>          {}
>>
>>      constexpr operator int() const noexcept {return d_;}
>> };
>>
>> day d(623);  // no undefined behavior
>>
> The UB is when you need to build a date if the day is not on the 
> range. E.g. the implementation could use some arrays indexed with the 
> day and access memory that has no sense.
> If we are sure that a day is in the range 1..31, this kind of 
> assumptions can be done on the implementation. The implementation 
> could not do it if the day value has not been validated previously or 
> behavior would be undefined.
>
>> The rationale for not checking if day is within a valid range (like I 
>> did for http://home.roadrunner.com/~hinnant/bloomington/date.html), 
>> is simply performance.
>>
>> One can not completely validate a day without the knowledge of the 
>> year and month.  There are two design spaces to explore:
>>
>> 1.  Validate as much as you can as early as you can.  This was the 
>> approach taken by my 2011 paper and which was criticized for low 
>> performance.
>>
>> 2.  Validate only once when you have the complete information.
>>
>> 1. didn't work.  So now I'm proposing 2.  I'm flexible. :-) There is 
>> no undefined behavior involved.
>>
>>
> Are you saying that you would check the day is in range 1..31 before 
> accessing such an array when using the value to build a valid date?
>
> I'm also flexible, and this was the reason I moved to no_check. Maybe 
> this is ugly, but covers the needs.
> * No validation if not desired so no loss of performances.
> * Validation is easier than no validation, so the user code is more 
> robust.
>
>
>
To be concrete: In my implementation I have the following tables (some 
of them based on your implementation Howard)

     day::rep                 days_in_month_[2][13];
     day_of_year::rep    days_in_year_before_month_[2][13];
     month::rep            day_of_year_to_month_[2][366];
     day::rep                 day_of_year_to_day_of_month_[2][366];
     day_of_year::rep    month_day_to_day_of_year_[2][12][31];

Access to these tables needs that the month is in range 1..12, 
day(_of_month) in 1..31, day_of_year 1..366.

Vicente