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

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-16 12:57:50

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

> David Abrahams <dave_at_[hidden]> writes:
>
>> Raoul Gough <yg-boost-users_at_[hidden]> 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 <boost/iterator/indirect_iterator.hpp>
> #include <boost/shared_ptr.hpp>
> #include <list>
>
> int main ()
> {
>   typedef std::list<boost::shared_ptr<int> > 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