Re: [Boost-users] iterators must go

Subject: Re: [Boost-users] iterators must go
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2009-05-15 14:10:25

Emil Dotchevski wrote:
> On Fri, May 15, 2009 at 8:15 AM, John Dlugosz <JDlugosz_at_[hidden]> wrote:
>   
>>> The three-iterators part was somewhat handwaved-over as well.  Take
>>> this bit of current code, for example:
>>>
>>>     auto i = find(c.begin(), c.end(), some_pred());
>>>     rotate(c.begin(), i, c.end());
>>>
>>> How do you do that nicely with ranges, when he has find returning a
>>> range?  (Since right now, it implicitly actually returns 2 ranges.)
>>>       
I don't know what Andrei intended for this case, but here's how I would
do it.
The BidirectionalRange concept looks something like this:

concept BidirectionalRange<R> : ForwardRange<R> {
  reference back(R&);
  const_reference back(const R&);
  R& pop_back(R&);
}

(Note: I have no idea how Andrei's concepts look in detail:)

Extend this with another function. The nature of bidirectional ranges
implies that this can always be supported, I think.

R prefix(R full, R suffix);

Precondition: suffix is a suffix of full, which means that you can get a
range equivalent to suffix by repeatedly calling pop_front(full)
Returns: a range r such that chain(r, suffix) is equivalent to full

Then your example can be written as:
range_t full;
range_t suffix = find(full, element); // or find_if(full, some_pred())
rotate(prefix(full, suffix), suffix);

>>> And how does insertion work?  Do we still need to keep the iterators
>>> around for insertion position?
>>>       
I think a ranges can be used as insertion positions. The element could
be inserted just before or after the start of the range. The details
have to be worked out, like if it's before or after, and if it's before,
if the range grows to include the element.

Sebastian