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