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 13:46:10

Le 03/05/13 18:06, Vicente J. Botet Escriba a écrit :
> Le 03/05/13 16:58, Howard Hinnant a écrit :
>> I have been reading with interest this thread, but have been sitting
>> on my hands until now. After all this is a gsoc project for Anurag,
>> not for me or anyone else.
>> But as long as everyone seems free to throw in their design
>> preferences, I will add mine, several of which I've already seen
>> repeated here, but some not.
>> Unchecked interface:
>> --------------------
>> date(year y, month m, day d);
>> This is the only order, there is no checking, the year, month and
>> date objects do no validation themselves. They exist only to
>> disambiguate the order of this low level constructor. This single
>> order is chosen above any other because of the ISO standards. The
>> use of the year, month and day objects add some type safety with no
>> run time overhead, and so are acceptable. Each of these objects will
>> *explicitly* convert from int:
>> date(year(2013), month(5), day(3)); // ok
>> date(2013, 5, 3); // compile time error
>> I dislike the use of no_check_t at this level because I see it as
>> unnecessarily verbose and ugly, and I'll have to look up how to spell
>> it every time I use it (see the checked interface for why).
> Hi Howard,
> my guess with no_check was to make it more difficult to build an
> unvalidated date than a validated one. Wouldn't an beginner user start
> using the unchecked constructors before the factory functions?
>> Checked interface:
>> ------------------
>> I like the use of factory functions here. I also like an
>> easy-to-remember, convenience, forgiving, type-safety. My
>> still-preferred spelling for the factory functions (yes, more than 1)
>> is:
>> date d = year(2013) / month(5) / day(3);
>> date d = year(2013) / month(5) / 3;
>> date d = month(5) / day(3) / year(2013);
>> date d = month(5) / day(3) / 2013;
>> date d = day(3) / month(5) / year(2013);
>> date d = day(3) / month(5) / 2013;
>> These 3 orders are chosen among the possible 6 because these are the
>> 3 that people actually use:
>> The first two units have to explicit. The last unit can be
>> implicit. Other rules are possible, but this one is a nice
>> compromise between convenience and simplicity. It is an easy rule to
>> remember, and the rule is easily checked by the compiler at compile
>> time.
>> I like this spelling of the checked factory function over:
>> make_unchecked_date(2013, may, 3);
>> or
>> make_valid_date(2013, may, 3);
>> because I know I will remember how to spell the former 3 years from
>> now, but I will have to look the latter up in a reference, unless I'm
>> dealing with dates often enough that I memorize it.
> Again I proposed these functions for the no_check date construction.
> Nothing to be with the checked one. Anyway I don't like them more that
> the no_check constructor.
> I like the factories for the check interface.
>> In both interfaces, the year, month and day objects do no validity
>> checking. The validity checks in the checked interface happen only
>> at the time the full date is constructed.
> I would expect that month and year could be check its validity so no
> check is needed when using constant objects. BTW, Howard, could you
> comment on my post about date literals for day and year?
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?


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