Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-04 14:44:01

On May 4, 2013, at 12:24 PM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:

> On May 4, 2013, at 7:57 AM, Rob Stewart <robertstewart_at_[hidden]> wrote:
> 
>>> 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;
>> 
>> To implement those, you must either introduce intermediate types, like year_and_month, with an overloaded operator /, or you need expression templates to shuffle the argument order before forwarding to a single, checked, date constructor.
> 
> Correct, I was strongly leaning towards the former: intermediate types like year_and_month.  And an open question is whether or not year_and_month would be a useful type to the client outside of this role.  E.g. would it be useful to perform month arithmetic on a year_month object?  Would it be helpful to get the number of days in a month out of a year_month object?  Or is year_month simply an implementation detail that the client never sees?
> 
> Personally I am still exploring these questions.

I suppose there could be some limited use for such types, but I suspect it would be better that they be implementation details.

One thing to consider in all of this, is the effect on debugging. The more objects created, the more stack frames to step through. That shouldn't be a primary consideration, but it can be useful to break ties.

___
Rob

(Sent from my portable computation engine)