From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-11 10:01:02
On Sun, 11 Apr 2004 05:27:07 +0100, Val Samko wrote
> I think it is natural to back up to the last day of
> the month, if the day we have (i.e. 31 in this case) is not present
> in that month.
I agree that backing up seems like the most common desire...
> I think, the first approach (non member functions) is better, since
> a) these function do not need to know the implementation details of
> the date class
> b) having some other date class I could easily implement equivalent
> functions, keeping the syntax consistent.
Ok.
> JG> date next = ld + months(13);
>
> JG> There are some technical complications with the last syntax,
> JG> but it should be doable given some time ;-)
>
> Thoughts? what sort of complications?
> struct months { months(int m) : mo(m){}; int mo; };
> date operator + (const date& d, const month& m) { return
> add_month(d, m.mo); }
Hmm, point taken. That said, if I add this to the library people will
(correctly, I think) expect the following:
date d1 += months(3);
date d2 = d1 - months(2);
date d3 -= months(2);
date d3 = d3 + months(-2);
to work correctly. The code we have sketched so far won't handle this
correctly. Going even further, I don't see why the following isn't allowed:
ptime t1(d1); //d1 at midnight
t1 = t1 + months(2);
And I think this same logic applies to 'years' and 'weeks' as well. This
would finally unify the arithmetic concepts in the library -- not to mention
make an awful lot of date calculation code very clean.
> Anyway, I think, three namespace level functions would be sufficient.
As you can see, I have a slightly grander plan, but it should be compatible
with your needs. Do you want these functions in CVS now or are you going to
patch your release for now?
Jeff