
Boost : 
From: Chris Trengove (trengove_at_[hidden])
Date: 20030818 22:25:37
I have some concerns about the implementation of the "period" concept, as
given in period.hpp. First of all, the documentation (for, say, date_period)
talks of the constructor
date_period(date begin,date last)
as creating a period as [begin,last). But really what is meant here is that
the "last" parameter is actually going to become the "end" of the period.
This is clear from the implementation in period.hpp, which is
template<class point_rep, class duration_rep>
inline
period<point_rep,duration_rep>::period(point_rep begin, point_rep end) :
begin_(begin),
last_(end  duration_rep::unit())
{}
In the other words, the last_ member is initialised by backing up one unit
of time from the "end".
I think there are two errors in the implementation of the period class,
perhaps caused by this confusion between "last" and "end".
1) is_null() is implemented as
return last_ <= begin;
which means that a period of length 1 is judged as being "null". The correct
implementation should be
return end() <= begin;
or
return last < begin;
2) operator<() is implemented as
return (last_ <= rhs.begin_);
and this should be
return (end() <= rhs.begin_);
or
return (last_ < rhs.begin_);
Also, I think that the implementation would be simpler and more efficient if
_end was chosen as the data member, rather than _last. As presently
implemented, there are quite a few calls to end(), which involves
calculating
last_ + duration_rep::unit();
each time. I believe that if _end is chosen as the data member, then the
entire class can be implemented without any such calculations. The only one
would be in the implementation of last() itself, which would become
template<class point_rep, class duration_rep>
inline
point_rep period<point_rep,duration_rep>::last() const
{
return end_  duration_rep::unit();
}
Chris Trengove
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk