Subject: Re: [boost] [chrono/date] conversion between concrete dates
From: Roland Bock (rbock_at_[hidden])
Date: 2013-05-11 10:41:59
On 2013-05-11 15:22, Rob Stewart wrote:
> On May 11, 2013, at 5:54 AM, Roland Bock <rbock_at_[hidden]> wrote:
>> On 2013-05-08 18:08, Vicente J. Botet Escriba wrote:
>>> 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);
>> 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++?
> If the types are unambiguous, such as with day, month, and year types, then any order can be supported. Those comfortable with a non-ISO order can do what they prefer with type safety.
Sure, you could, and if the library were a direct user interface, I'd
say: "Nice baby steps, but not nearly there yet" ;-)
But I don't see a benefit for a library to support different date
formats in code. And in terms of code readability, I think it is not a
good idea to allow too many options, even though they are typesafe. The
next programmer to read your code might be more comfortable with a
different order and might not think like a compiler (and be confused).
>> 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 :-)
> You misunderstood the conversion context. There are several formats in contemplation: serial, days since an epoch; ymd; day of year; week of year; etc. conversions among them are sometimes costly, so the notion is to make them explicit.
True. As I wrote in reply to Vicente, I obviously missed major parts of
the discussion so far, so I am not going to argue about the conversion
before I read more about that :-)
>> I'd therefore prefer another operator, e.g. operator <<
> That operator is for I/O, even if unsupported. (Someone might want to add I/O, even if not standardized.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk