Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-05 05:26:20
Le 04/05/13 23:16, Anurag Kalia a écrit :
> Good suggestion. Now to consolidate my view up till now, I have following
> types of date construction in mind:
> 1) Unchecked:
> simple ymd constructor -
> date(year, month, day);
> date(day, month, year);
> date(month, day, year);
> 2) Checked:
> "natural" factory function -
> (the last argument also has an int for succinctness)
> year / month / day;
> day / month / year;
> month / day / year;
> This notation extends as -
> weekday[n] / month / year;
Does the preceding build a contextual or non-contextual date?
> To be noted:
> 1) I have dropped no_check option. It is verbose and I never liked that. The
> constructor has a 'raw' feeling to it that lends itself well to an unchecked
> constructor. We have the other two categories of functions that check the
I have not yet a clear position on this concern.
It is clear to me that /() factories must be checked as we can not state
> 2) I include the named factory functions because there seems no other way to
> make a date with so myriad options. The consistent naming indicates that the
> same object is being produced; which is exactly what needs to be said.
Do you mean that make_date would provide more services than the
expression template using operator/()?
> 3) The "natural" construction (really, we need some name for them) is
> actually natural. I particularly like the dmy notation in this case, with
> last argument as int:
> day(25) / dec / 2013;
> As for the constants, the jan, feb, ..., dec as well as sun, ..., sat are
> Moreover, there are also _1st, _2nd, ... , _31st and last.
> There is nothing for these : day(1) and week(4). It is because the are not
> widespread and this notation is much more clear than any enumeration.
Sorry I missed your position. Could you clarify what are you proposing?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk