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

Le 04/05/13 17:26, Howard Hinnant a écrit :

On May 4, 2013, at 2:56 AM, Vicente J. Botet Escriba wrote:

...

So if the day/month and year are just names and don't ensure range I would need to start by validating their range in [0] so that if some of them is out of range the function return false;

This mean that the user is not able, using the type system, to help the implementation to reduce needed check. I have no measures of the impact of these 3 range checks (6 comparisons). I just wanted to avoid them.

Even if we use other kind of cache, I don't see how the cached data can be accessed without checking the range are correct.

E.g. An alternative implementation using a cache for the year_month_cache

bool days_date::set_if_valid_date(year y, month m, day d) noexcept { // [0] auto c = year_month_cache(y, m); // [1] if (d.value() >= c.days_in_month) return false; x_ = c.days_before + d.value(); // [2] return true; }

This needs that y and m anre in range at [1] and d in in range at [2].

Howard, could you tell me if you find something wrong on my analysis? I want to be too purist? I think I see the disconnect. Simplifying as much as possible (hopefully not too much), you prefer:

days_date(year::rep, month::rep, day::rep, no_check_t);

whereas I prefer for the same functionality:

days_date(year, month, day);

or for the sake of removing part of the debate:

days_date(year, month, day, no_check_t);

Your design doesn't require that year, month and day objects be "validation free", but mine does. Could you tell me why your is "validation free"? I'm sure we all will learn something interesting.

And then I'm also seeing constructors like this running around (which I also experimented with):

month::month(int m, no_check_t); I ind it ugly, but it does what is requested.

Exploring design decisions like these would make a pretty good topic for a gsoc. :-)

I don't know if Anurag will be for. Best, Vicente