Raoul Gough writes:

David Abrahams writes:

...

Raoul Gough writes:

...

Using gcc 3.2 (on MinGW) the template parameter defaults for indirect_iterator_generator don't work with shared_ptr. This has been discussed* on the list before, but there doesn't seem to have been a user-friendly resolution to the issues involved (at least not in release 1_30_0).

Right. The user-friendly solution is to use the iterator adaptors in the current Boost CVS. There won't be a fix for 1.30.0.

Hi Dave,

Thanks very much for your reply. I've switched to the CVS head, and can get my test case to compile as follows:

#include #include #include <list>

int main () { typedef std::list ListType; typedef ListType::iterator BaseIterator; typedef boost::indirect_iterator<BaseIterator> Adapter; }

Is that about right?

Yep.

It looks like the main documentation isn't up to date yet, since it links to libs/utility/indirect_iterator.htm which still talks about indirect_iterator_generator.

Right.

On a different note, /libs/iterator/doc/facade-and-adaptor.html says:

If the default is used for Value, then there must be a valid specialization of iterator_traits for the value type of the base iterator.

That's not quite accurate. The actual rule is: if the value_type of the Base iterator is a class with a nested ::element_type, remove_const< iterator_traits<Base>::value_type::element_type

::type

will be the value type of the resulting iterator. Otherwise, there must be a valid iterator_traits specialization of iterator_traits for the value type of the base iterator. We probably ought to define a public referent<T> metafunction in namespace boost which implements that logic, so that people can specialize it.

Is a full iterator_traits actually necessary? Just seems to me that there is conceptual difference between (let's say) dereferencable_traits (which any proxy type could have) and a full-blown iterator_traits (which smart pointers probably wouldn't have).

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

David Abrahams writes:

David Abrahams writes:

...

We probably ought to define a public referent<T> metafunction in namespace boost which implements that logic, so that people can specialize it.

That's done; the docs still need to be updated to reflect that fact though.

Alright! So I can now specialize boost::referent for my own smart pointer template: namespace boost { template<class T> struct referent { typedef T type; }; } 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. -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta

David Abrahams writes:

Raoul Gough 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; }; 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 BTW, does it ever make sense to have pointer_type != (value_type *) or reference_type != (value_type &) ?? -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta

David Abrahams writes:

Raoul Gough writes: [snip]

...

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.

After realising that an iterator is just a kind of handle that supports movement (according to its iterator_category) I figured that the traits subclassing was an accurate representation. Doing it this way, with handle_traits more general than iterator_traits (and at least as visible to client code) it seems like a good central repository for the type information. If you only want info about operator*() then you can use handle_traits<T> without knowing whether T is really an iterator. It also helps to document the requirements. For example, a valid handle class T requires handle_traits<T> and an operator*() that returns handle_traits<T>::reference_type. A valid iterator T is a handle that additionally has iterator_traits<T>, and movement functions dependant on iterator_category. indirect_iterator<T> requires that T is a valid iterator and that iterator_traits<T>::value_type is a valid handle. Seems neat to me, but who would have designed std::iterator_traits that way back then :-) -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta