From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-25 10:16:11
From: "Douglas Gregor" <gregod_at_[hidden]>
> > and I think that iterator_traits<TrivialIterator> is
> > deliberately left undefined as most of the members don't make sense.
> difference_type doesn't make sense, of course, but the others? value_type
> obviously necessary, reference is just add_reference<value_type>::type;
reference r = *x; // binding reference to rvalue proxy
To be useful, reference must be the return type of *x, not just value_type
> pointer can be useful as a raw pointer to value_type (e.g., the result of
> addressof(*trivial_iterator) is of this type).
"value_type *" can give you that - except for the const problem.
addressof(*ti) may be of type "proxy*".
> > In
> > addition, the value_type of an iterator is always non-const, whereas the
> > element_type of a pointer is traditionally the exact template parameter,
> > including cv qualifiers.
> Er? const_iterators have a const value_type.
> And what about iterator_traits<T const *>?
What about it? value_type is T.
> > Bundling a set of traits in a single class inevitably creates problems.
> > leaning towards element_type_of<P>::type (template parameter of P or T
> > T*) and reference_of<P>::type (exact return type of *p, typically
> > element_type_of<P>::type &, but may be proxy.)
> Bundling traits does create problems, but so does having a huge number of
> separate traits classes that one needs to remember.
What are the problems of having a "huge number" (as in two, or five) of
separate traits classes? If you can remember
you can remember
> As I see it, we already
> have established concepts and traits that can handle (smart) pointers
> relatively well. We know we can do better (e.g., Jeremy's improved
> categories) for iterators and pointers in a way that is backward
> I think that we should use Jeremy's iterator categories, augmented with a
> StationaryTraversalIterator concept.
If you are going to create boost::iterator_traits extended to handle smart
pointers, I'm not going to stop you. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk