Boost logo

Boost :

Subject: Re: [boost] [gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?
From: Adam Merz (adammerz_at_[hidden])
Date: 2010-05-31 20:17:47


Christian Henning <chhenning <at> gmail.com> writes:
> Easy enough, correct. I did this change to my local boost for a couple
> of gil's iterators. I have less compiler errors now. Do older MSVC
> versions and other compiler define std::random_access_iterator_tag? If
> though, I could add this fix to boost, as is.

Yes, std::random_access_iterator_tag is standard and portable; you just need to
#include <iterator> to use it.

That said, I'm dubious as to whether this is the only fix (iterator_facade's
category decaying mechanisms strike me as questionable) or even the correct fix
(it violates the standard's requirements), so in my opinion this warrants a
larger discussion, especially since at least one other released library is
affected by the exact same issue.

> I really have a hard understanding where and when the metafunction
> boost::detail::iterator_facade_default_category is actually reducing
> bit_aligned_pixel_iterator to an input iterator?

The instantiation path from bit_aligned_pixel_iterator to
iterator_facade_default_category is:

boost::gil::bit_aligned_pixel_iterator ->
boost::iterator_facade ->
boost::detail::iterator_facade_types ->
boost::detail::facade_iterator_category ->
boost::detail::facade_iterator_category_impl ->
boost::detail::iterator_facade_default_category

> When I do this:
<snip code>

When bit_aligned_pixel_iterator.hpp lines 47 and 53 are both changed, this code
produces it_cat_t == std::random_access_iterator_tag for me. Did you change
both lines?

> Though, where does the "decaying" happen?

The metaprogramming logic inside of iterator_facade_default_category is fairly
straightforward, so I'm not sure what to say other than
facade_iterator_category.hpp line 72. :-P


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk