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
>> 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 == 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
> (or there is no acceptable conversion)
> 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 == Integer(2));
> but the error message stays the same.
The right check would be:
BOOST_CHECK(Integer(it) == 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk