Boost logo

Boost :

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
> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at