Boost.Iterator filter_iterator issues
Hi, 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. Is it a requirement for the iterator being adapted by filter_iterator to catch decrements past the containers begin range? The following test will iterate 'iter' past containers begin iterator which will trigger a debug assertion on MSVC. template<class _Iterator> void dec_iterator(_Iterator iter) { BOOST_CHECK(*iter == 2); --iter; // iterates past begin } BOOST_AUTO_TEST_CASE(test_filter_iterator) { using namespace boost::assign; typedef std::vector<int> container_type; container_type values = list_of(0)(1)(2); dec_iterator(boost::make_filter_iterator(std::bind2nd(std::greater<int>(), 1), values.begin(), values.end())); } Please help me clarifying this issue. Best regards, christoph
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
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
participants (2)
-
Christoph Heindl -
Steven Watanabe