[boost] Re: iterator_facade operator[]

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2004-03-09 09:54:30

David Abrahams wrote:
> Alberto Barbati <abarbati_at_[hidden]> writes:
 >
>>David Abrahams wrote:
 >
>>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.

I should have the docs more thouroughly before posting. Now I understand 
the situation better and I agree with the design. The docs are quite 
clear about it, but I bet that this issue will soon be the top FAQ about 
Boost.Iterator ;-)

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

Instead of trying a way to avoid the proxy, we could just help the 
compiler resolving certain kind of expressions like it[0] == 2. For 
example if the proxy implemented operator== like this:

template <class Rhs>
friend bool operator == (const operator_brackets_proxy& lhs, const Rhs& rhs)
{
   return *(lhs.m_iter) == rhs;
}

we would not impose any additional requirement on the iterator unless 
the operator== is really needed. The problems I see with this 
suggestions are:

1) this will address only operators, it still may not help in some other 
contexts;

2) we should overload all operators twice and be careful about it[0] == 
it[1]. A *lot* of code.

3) to do things *really* right we definitely need some typeof-like 
facility to determine the return type of the operators.

I guess that point 3 rules my suggestion out for the next several years, 
but I hope it still might be thought provoking :-)

Alberto