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

3 May 2013

      Le 03/05/13 19:53, Howard Hinnant a écrit :
...
On May 3, 2013, at 1:46 PM, "Vicente J. Botet Escriba"  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.

Best,
Vicente