Boost logo

Boost :

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


David Abrahams wrote:
> on Sat Aug 30 2008, "Giovanni Piero Deretta" <> 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
with nested filter_iterators. (untested)

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

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at