[boost] Re: iterator_facade operator[]

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-08 09:48:00

Alberto Barbati <abarbati_at_[hidden]> writes:

> David Abrahams wrote:
>
>> What makes you say that there's something wrong with
>> iterator_facade's
>> operator[]?  Is it possible that the regression test makes invalid
>> assumptions about the way an iterator's operator[] is supposed to work?
>
> The problem is triggered by the expression
>
>      BOOST_CHECK(it[0] == 2);
>
> found in file base_test.cpp line 157. VC .NET 2003 gives the following
> error message:
>
> error C2678: binary '==' : no operator found which takes a left-hand
> operand of type
> boost::detail::operator_brackets_result<Iterator,Value,Reference>::type'
> (or there is no acceptable conversion)
> with
> [
> Iterator=boost::cb_details::cb_iterator<boost::circular_buffer<Integer>,Integer>,
> Value=Integer,
> Reference=Integer &
> ]
>
> "it" is defined as circular_buffer<Integer>::iterator. As the right
> hand side is not an "Integer" I also tried writing:
>
>      BOOST_CHECK(it[0] == Integer(2));
>
> but the error message stays the same.

The right check would be:

    BOOST_CHECK(Integer(it[0]) == 2);

The return type of a random access iterator's operator[] is only
required to be *convertible* to its value_type.

> I am uploading a revised version of
> circular_buffer_new_iterators_v2.zip that overrides operator[]. All
> regression tests passes with VC7.1. I also made the implementation
> members private and fixed the comments.
>
> Anyway you'll agree that the issue is quite general and it might be
> interesting to investigate if we could find a solution at the
> iterator_facade level.

We've given it a lot of thought already.  In general there's no way
to detect that a given iterator implementation will return a
reference to a persistent object from its dereference
implementation.  See
http://www.boost.org/libs/iterator/doc/iterator_facade.html#operator.

If you can come up with a way to decide reliably that the proxy is
unneded, that'd be great -- but I doubt it can be done.  Anyone who
really cares about returning a reference from operator[] can do what
you did.  In general, though, there's no reason for any algorithm to
use an iterator's operator[] anyway, so fulfilling the random-access
requirement for operator[] is really a formality and it doesn't need
to be optimal.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com