Boost logo

Boost :

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

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

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


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