Re: [boost] lifetime of ranges vs. iterators

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-08-30 17:18:17

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