Re: [boost] iterator_adaptors and shared_ptr

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-08-07 14:00:29

> Are you supplying types for the Value, Reference, etc. parameters of
> indirect_iterator_generator, or are you relying on the defaults? I think
> the problem is that you are relying on the defaults, which is to look at
> std::iterator_traits. If instead you supply the Value type, etc. I think
> things should work.

Yes, this would clearly work. I'm relying on the defaults, by way of 
make_indirect_iterator(vector_of_smart_ptr.begin()). But I think that 
that really ought to be made to work somehow. Having to use:

typedef indirect_iterator_generator<vector<shared_ptr<MyClass> >
::iterator,MyClass>::type my_iterator;

takes away a bunch of ease-of-use points for indirect_iterators for 
this case. (I would have called it a common case, but no one's 
mentioned it before now, so maybe it's not...) And the errors that I 
get for failure aren't very user-friendly, so less knowledgeable users 
will probably just decide not to bother to try to use it...

IMHO to do this right this is something *like* an iterator_traits, it's 
a dereferenceable_traits. Unfortunately, the right way is to have 
iterator_traits defined in terms of dereferenceable_traits, but that 
requires a change to the standard :(. Alternatively, shared_ptr (& 
cousins) could define value_type, pointer, and reference, without 
defining difference_type or iterator_category -- meaning the parts of 
iterator_traits that are needed in this context would work fine, but 
the other parts would fail as they should. That latter might be the 
cleanest improvement without going through change to the standard...

George Heintzelman
georgeh_at_[hidden]