Re: [boost] [gil] how does dereference_iterator_adaptor defines it's iterator category?

Subject: Re: [boost] [gil] how does dereference_iterator_adaptor defines it's iterator category?
From: Adam Merz (adammerz_at_[hidden])
Date: 2010-06-01 05:27:03

Christian Henning <chhenning <at> gmail.com> writes:
> I'm still investigating compilation errors with my gil extension while
> compiling on MSVC10. I have exchanged
> boost::random_access_traversal_tag with
> std::random_access_iterator_tag with all gil iterator types. This
> solved some of my problems. Some still remain. Here is what I have
> discovered.
> 
> When using a boost::gil::kth_channel_view_type with bit_aligned image
> types I'm running into the same problem I had with just using
> bit_aligned image types. Now kth_channel_view_type uses a
> boost::gil::dereference_iterator_adaptor for iteration purposes. This
> adaptor defines it's iterator category as
> boost::detail::iterator_category_with_traversal<std::input_iterator_tag,
> boost::random_access_traversal_tag> which is wrong. I have been trying to
> figure out where this definition is coming from. But I'm not able to. All
> occurrences of random_access_traversal_tag have been removed from gil code.
> Which leads me to believe it's coming from boost itself somewhere.
> 
> Here is some code displaying the problem.
<snip code>

dereference_iterator_adaptor uses iterator_adapter with a traversal/category
type of boost::use_default. The way use_default behaves is to discover the
category/traversal type of the iterator it's adapting
(bit_aligned_pixel_iterator<...> in this case), then convert that into a
traversal type. In this case, bit_aligned_pixel_iterator has a category of
std::random_access_iterator_tag, which gets converted back into
boost::random_access_traversal_tag. iterator_adapter then hands off its work to
iterator_facade, giving iterator_facade this traversal type instead of the
category/traversal type the iterator had originally. iterator_facade then puts
its decaying logic into action. In this case it decays from random access into
input because of the whole reference vs. proxy object issue, behaving
identically to using bit_aligned_pixel_iterator<...> directly with
boost::random_access_traversal_tag.

The fix in this case is to have dereference_iterator_adaptor forward the
wrapped iterator's category to iterator_adaptor rather than pass use_default,
so the category doesn't get converted back to a traversal type. Change lines
47 and 53 in pixel_iterator_adaptor.hpp from 'use_default' to 'typename
std::iterator_traits<Iterator>::iterator_category'.