Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-11-25 22:34:11

On Tue, Nov 25, 2008 at 10:13 PM, Tomas Puverle
<Tomas.Puverle_at_[hidden]> wrote:
> "Daniel Walker" <daniel.j.walker_at_[hidden]> wrote in message
> news:a733b05a0811251831j57cd6403yc64f00af9b56a6bf_at_mail.gmail.com...
>
>> Let's stick to the facts. The Range concept definitions went from
>> supporting up to 6 procedural abstractions (begin(r), end(r),
>> empty(r), size(r) rbegin(r), rend(r)) to supporting 2 (begin(r),
>> end(r)).
>
> Daniel,
>
> I just ran into this problem today, while trying to fix some of the code
> that broke because of the 1.35 changes.
>
> The specification of size() has changed from 1.33.1 to 1.37, presumably in
> 1.35.  In 1.37, it requires  RandomAccessRange while in 1.33.1 it only needs
> ForwardRange.

I'm looking at the 1.37 docs right now and I don't see size(r). It
should be here
http://www.boost.org/doc/libs/1_37_0/libs/range/doc/range.html#forward_range

If you're using it at all, it's not part of the concept definitions.
So formally, you can't assume that all types modeling ForwardRange
support it.

> This is not a terribly difficult problem for me to fix but it's another
> breaking change.
> I think the library is trying to enforce certain performance requirements.
> IMHO, the restrictions should be enforced by the library user, not the
> library itself.

size functions usually only require ForwardIterators, though the
implementation is more time efficient for RandomAccess. See
std::distance().

> Since I wasn't involved in the original design, I have a question though:
> Did the original design require that each Range be at least Bidirectional?
> The requirement of rend() and rbegin() is telling me that was.

No, see http://www.boost.org/doc/libs/1_34_1/libs/range/doc/range.html.
rend() and rbegin() were only available for models of BidirectionalRange.

> What am I missing?

To this day, the same refinement hierarchy exists. ForwardRange for
ForwardIterators refines SinglePassRange for SinglePassIterators, etc.
It's a good design. It's just that now the refinements are in name
only, really. Since all functions have been removed from the concepts
except for begin() and end(), the only difference between the
refinements is the iterator concept modeled by
range_iterator<X>::type, which doesn't buy you much.

Daniel Walker