Re: [boost] Re: Re: pointer_traits ?

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
> dereferenced,

We already need a separate dereference_traits for iterators because of this 
problem.

> 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...

> 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 *>?

> 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 
StationaryTraversalIterator concept. 

        Doug