Boost logo

Boost :

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.

> 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,; }

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at