Steven, 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 undefined. Thanks again for clarifying, Christoph On Sun, Sep 27, 2009 at 4:34 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
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() { while(!this->m_predicate(*--(this->base_reference()))){}; }
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 [2]. 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: http://lists.boost.org/mailman/listinfo.cgi/boost