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