From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-09-25 09:49:05
On Wednesday 25 September 2002 09:28 am, Peter Dimov wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
> > trivial_iterator_tag
> > See the TrivialIterator concept documentation here:
> > http://www.sgi.com/tech/stl/trivial.html
> I think that a separate dereference_traits (or whatever) class would be
> better. Trivial iterators aren't required to return a reference when
We already need a separate dereference_traits for iterators because of this
> 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 is
obviously necessary, reference is just add_reference<value_type>::type;
pointer can be useful as a raw pointer to value_type (e.g., the result of
addressof(*trivial_iterator) is of this type).
difference_type doesn't make sense for OutputIterator's either, so it's not as
if we're breaking new ground here...
> 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 *>?
> Bundling a set of traits in a single class inevitably creates problems. I'm
> leaning towards element_type_of<P>::type (template parameter of P or T in
> 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. 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 iterator
categories) for iterators and pointers in a way that is backward compatible.
I think that we should use Jeremy's iterator categories, augmented with a
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk