Boost logo

Boost :

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 08:39:14


Le 04/05/13 14:32, Rob Stewart a écrit :
> 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.
>
>
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk