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 09:14:11

Le 03/05/13 13:39, Rob Stewart a écrit :
> On May 2, 2013, at 10:19 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
>> Vicente Botet wrote
>>> Take in account that this is not just about naming parameters but about defining the design space. Note that
>>> day(32)
>>> will fail and throw an exception. If you don't want the check to be done you have the possibility to use a no_check tag
>>> day(7, no_check)
> I don't see the value of this. Yes, you can ensure the value is < 31, but you can't ensure that it doesn't exceed the range for a given month in the day type. Therefore, the validation should be done by the date constructor.
> IOW, I see two classes: year and day that are trivial value types holding an unsigned type with no validation. They exist solely to apply type information.
I could admit that the independent validation for the day could be
redundant, but the year can be validated independently, so providing
validated year don't need any further validation.
>>> In the same way the library provided some constant object for month we could add constant objects days for days, e.g. d_07 which is correct by
>>> definition. So the preceding examples could become
>>> date d(d_7,dec,year(2013,no_check));
>>> date d = d_7 / december / year(2013);
> At the very least, the names would need to be dayN or day_N. "d" seems insufficient. At that point, "day()" is only one or two characters longer.
> I don't like the day-of-month constants.
I have posted another thread for date suffixes.


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