Re: iterator adaptors

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-12-21 16:59:02

--- In boost_at_[hidden], scleary_at_j... wrote:
> > From: John E. Potter [mailto:jpotter_at_f...]
> > I see typedef T const& reference.  The required typedef is 
> > reference. I understand your concern though.
> > 
> > > [2] I think the "pointer" type should be "const value_type *".
> > 
> > It really makes no difference.  Pointer is the type returned by
> > operator->.  That operator returns &operator*().  But, operator*
> > returns an rvalue and address of may not be used on an rvalue.

[...]

> However, there may be a problem with operator->, as you pointed 
> out.  In this case, (*i).m is well-defined, but i->m appears to be 
> unimplementable unless the iterator is buffered (see 24.1/1).  
> OTOH, maybe we can force it to work through some proxy pointer 
> return type.  Was this the intention of the Standard (I'm thinking 
> we could get away with disallowing "i->m" for input iterators)?

If I understand you correctly, I'm a little hesitant about defining 
pointer and reference in this way.  Recently, I wrote an iterator 
that defined a non-trivial reference type (and buffered value_type).  
One of the problems I came across was in using the iterator adapter 
classes that come with MSVC (back_inserter etc.) - the cause of the 
problem was precisely because operator*() wasn't defined to return 
the iterator's reference type.  So I vote for the status quo in 
allowing these types to be defined by the traits parameter.

On a related matter, if non-trivial reference types can be used, then 
might it be as well to allow a separate definition of this operator->
() via the policy parameter, rather than rely on reference::operator&
()?

Referring to Dave's comments about long symbol names, I don't think 
that it hurts to allow the policy class direct access to the traits 
class; the two are closely linked anyway.  This would have the side 
effect of simplifying the implementation, obviating the need to pass 
in the reference type using member template argument deduction.  It 
may make it more usable too - the user just has one class to worry 
about.  On the down side, we would lose the clean separation that 
allows const_iterator and iterator to be cleanly defined with just 
one policy (three classes, though, so maybe it's not so bad...)

I'd also be interested to know exactly what expressions are allowed 
when an iterator is dereferenced.  I've read that (*i).m and i->m are 
valid expressions, but what about (*i).m = v; or i->m = v; or
i->m *= v, or even i->mutating_function()?

Gavin.