Re: [boost] lifetime of ranges vs. iterators

30 Aug 2008

      AMDG

David Abrahams wrote:
...
on Sat Aug 30 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
...
Hum, this would means that every range needs to know how to construct
and deconstruct iterators of other ranges, at least if it wants to
guarantee that the minimum space possible is used.
It would be done with associated types and functions of the iterators.
Few iterators need to store that kind of redundant information, but when
you build an iterator type that *does*, it would be deemed "polite" to
specialize an appropriate trait and/or define the corresponding
overloads to allow it to be decomposed/re-composed.
I've been itching to rework Boost.Iterator recently, and this could make
a very nice enhancement.
How would this work:

concept IteratorWithEnd<typename Iterator> {
    Iterator get_end(Iterator);
    Iterator set_end(Iterator, Iterator);
}

Taking filter_iterator, for example, this would allow the space to be 
minimized,
with nested filter_iterators. (untested)

template<IteratorWithEnd Iterator, class F>
class filter_iterator<Iterator, F> {
public:
    //...
    filter_iterator(Iterator begin, Iterator end, F f) : 
iter(set_end(begin, end)), f(f) {}
    filter_iterator& operator++() {
        ++iter;
        while(iter != get_end(iter) && !f(*iter)) ++iter;
        return(*this);
    }
    friend Iterator get_end(const filter_iterator& self) {
        return(filter_iterator(get_end(self.iter), get_end(self.iter), 
self.f))
    }
    friend Iterator set_end(const filter_iterator& self, const 
filter_iterator& other) {
        return(filter_iterator(self.iter, get_end(other.iter), f));
    }
private:
    Iterator iter;
    F f;
};

In Christ,
Steven Watanabe