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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-04 08:32:06

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

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

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.

___
Rob

(Sent from my portable computation engine)