Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk