Re: [boost] Boost.Iterator filter_iterator issues

Subject: Re: [boost] Boost.Iterator filter_iterator issues
From: Christoph Heindl (christoph.heindl_at_[hidden])
Date: 2009-09-27 02:46:35

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_at_[hidden]> 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
>