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-03 19:19:52

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at