Re: [boost] Re: Re: pointer_traits ?

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
is
> 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
[const] &.

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

Do they?

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

What are the problems of having a "huge number" (as in two, or five) of
separate traits classes? If you can remember

typename iterator_traits<It>::foo

or

typename It::foo

you can remember

typename foo_of<It>::type

right?

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

If you are going to create boost::iterator_traits extended to handle smart
pointers, I'm not going to stop you. :-)