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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-03 19:36:33

On May 3, 2013, at 7:19 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

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

In:

Unchecked interface:
--------------------

  date(year y, month m, day d);

If any of the y, m or d are out of range, it would index into those tables upon field->serial conversion (if asked for) and result in undefined behavior.

In:

Checked interface:
------------------

  date d = year(2013) / month(5) / day(3);
  date d = year(2013) / month(5) / 3;
  date d = month(5) / day(3) / year(2013);
  date d = month(5) / day(3) / 2013;
  date d = day(3) / month(5) / year(2013);
  date d = day(3) / month(5) / 2013;

There would be a single point of validation at the point where all of y, m and d are known, and there would be an error.  Presumably that error would be an exception if any of the inputs are not constexpr, or a compile-time failure if all of the inputs are constexpr.

Howard