Alberto Barbati <abarbati@iaanus.com> 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