Subject: Re: [boost] Boost.Iterator filter_iterator issues
From: Christoph Heindl (christoph.heindl_at_[hidden])
Date: 2009-09-27 02:46:35
thanks for answering. I was a little bit surprised by the fact that
the original start point of iteration wasn't considered when
decrementing the iterator. I probably missed the fact that
decrementing an iteration pointing to the beginning of a range is
Thanks again for clarifying,
On Sun, Sep 27, 2009 at 4:34 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> Christoph Heindl wrote:
>> I think I've found an issue with boost::filter_iterator when
>> decrementing a valid iterator without having any predicate evaluating
>> to true on its way back.
>> filter_iterator.hpp line# 93 states
>> void decrement()
>> which will ?clearly? pass beyond the initial start iterator if no
>> predicate evaluates to true.
> It's undefined behavior if you try to decrement an iterator like that.
>> Is it a requirement for the iterator
>> being adapted by filter_iterator to catch decrements past the
>> containers begin range?
> Consider an unfiltered range. e.g. [0, 1, 2].
> If you have an iterator pointing to the 0, then it
> is undefined behavior to decrement it, right?
> That's just the way the STL works. If you
> use a filter_iterator with the predicate _1 > 1,
> you get a range containing . Again, it's
> undefined behavior to decrement an iterator
> pointing to the 2. You can't decrement an
> iterator that points to the beginning of a range.
> In Christ,
> Steven Watanabe
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk