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

4 May 2013


      Le 04/05/13 14:32, Rob Stewart a écrit :
...
On May 3, 2013, at 7:05 PM, "Vicente J. Botet Escriba"  wrote:
...
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.
You can apply the same range checking in the date constructor as you intended for the day, month, and year constructors. There is no difference in performance, since the same checking is done.
Yes, there is one. When using constant/constexpr objects there is no 
need to validate at runtime its validity, they are valid by definition 
at compile time.

Best,
Vicente