Le 11/05/13 16:29, Roland Bock a écrit :
Le 11/05/13 11:54, Roland Bock a écrit :
On 2013-05-08 18:08, Vicente J. Botet Escriba wrote:
Hi,
as the conversion between concrete dates could be expensive I guess that these conversion must be explicit.
But this has some consequences when used the implicit conversion was hidden a not efficient implementation, e.g.
date ISO_week_start = mon <= jan/day(4)/y;
jan/day(4)/y should be ymd_date as is the efficient representation.
The date generator was declared as
date operator<=(weekday wd, date x); Hi,
Do you really want to allow/document/support/advocate the American date format in C++? Why not restrict the format to something close to ISO date format for ISO C++? That way you could introduce a new type, say ym_type and
ym_type operator/(year y, month m); date operator/(ym_type ym, day d);
Neither explicit nor implicit conversion necessary :-) We have suggested a more neutral factory
auto dt = make_date(year(2013), may, 11); Yes, I like that much better. The main point I was trying to make is
On 2013-05-11 15:13, Vicente J. Botet Escriba wrote: that using operators to mimic the way some people are used to writing a date is not necessarily the best idea.
May/11/2013 11.Mai 2013 11.5.13 2013-05-11 ...
There are just so many ways.
We need to choose one of the overloaded operators.
Allowing such formats in code just adds to confusion, IMHO. Why are you confused. Even if I don't use to use May/11/2013 but 11/May/2013 I don't see how
auto dt = may/11/year(2013); could confuse someone. What could this mean other than the declaration of a date.
Another question I have about this is: Is is really a good idea to use operator/()? It does prevent you from calculating ratios between periods, e.g.
int ratio = year(3)/month(4); // ratio = 9
I'd therefore prefer another operator, e.g. operator <<
year,month and day are unit specifiers not periods (years, months, days). The ratio is obtained using
int ratio = years(3)/months(4); // ratio = 9 Hmm, seems like I missed a lot of the discussion. I'll need to read up on that, but I admit it seems weird to me to have to distinguish between years as a period and year as a "unit".
unit specifiers, such a year, are not units but a way to name an instance of a given type. Periods are units
I mean, for instance 'm' is a unit, 10m is a distance (not 10ms), I guess ms stands for meters ;-) The unit is metres not meter and the suffix is m. All end with n -s, as seconds, hours, years, ... ft is another unit for distances, and there is no harm in dividing 10m by 5ft. The unit specifiers for meters could be used to mean the e.g. the Km 13 of a specific route.
Calendar units are a bit weirder than the MKS system, but still...
Best, Vicente