Re: indirect_iterator_generator<list<shared_ptr<X> >::iterator> again

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-17 10:13:31

Raoul Gough <yg-boost-users_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> writes:
>
>> Raoul Gough <yg-boost-users_at_[hidden]> writes:
> [snip]
>>> Really seems a bit weird that boost::referent wasn't already
>>> invented in the type_traits portion of the library, since it can be
>>> applied to any kind of pointer, iterator, etc... Anyway, it has
>>> neatened up my code quite a bit, thanks.
>>
>> It's a little quirky, yet.  If you define an iterator with a nested
>> element_type member it will do the wrong thing.
>
> I guess in an ideal world, we would have something like this:
>
> template<typename T> struct handle_traits {
>   typedef typename T::value_type value_type;
>   typedef typename T::pointer_type pointer_type;
>   typedef typename T::reference_type reference_type;
> };
>
> template<typename T> struct iterator_traits : public handle_traits<T> {
>   typedef typename T::iterator_category iterator_category;
>   typedef typename T::difference_type difference_type;
> };

I don't see why that's preferable to what we have now with referent.

> Since an iterator is-a handle with additional functionality
> (i.e. movability to one extent or another). In the case of
> indirect_iterator<T>, we would need valid instantiations for
> iterator_traits<T> and handle_traits<iterator_traits<T>::value_type>
>
> BTW, does it ever make sense to have pointer_type != (value_type *) or
> reference_type != (value_type &) ??

Yes to the latter; you can read all about it in the new iterator
adaptor / facade / concepts documents.  Also see
std::vector<bool>::iterator.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com