Hi folks, Stephan T. Lavavej:
if X is a mutable iterator, reference is a reference to T; if X is a const iterator, reference is a reference to const T,
If I'm reading this right, then an iterator whose 'reference' is not a reference is not an std iterator at all. If so, then my question (not necessarily to you, but to everyone) becomes: why does the Iterator library tag such an iterator with std::input_iterator_tag? Isn't this strictly wrong? Nathan Ridge:
You can take advantage of Boost's iterator concepts by modifying 'func' from your original post to dispatch on boost::iterator_traversal<TITerator>::type() instead of std::iterator_traits<TIterator>::iterator_category(), since traversal is the relevant aspect in that case.
In my experience, the easiest way to handle this painful reference requirement is to ignore it and pretend that the standard categories are only about traversal. I've never had anything break because of this.
'func' exists just to illustrate the issue that these iterators interact badly with the STL. I realize that I could dispatch on the boost traversal concepts, but my concern was interoperability with STL algorithms. Marc Glisse: + Nathan Ridge:
Is the OP's problem not an example of pretending that the standard iterator categories are only about traversal and having something break as a result?
I would say that my problem was misunderstanding what iterator_facade is trying to do. It's not clearly explained how the CategoryOrTraversal argument is translated into the interator_category, and in what cases the result is different from what one would intuitively expect. The docs state over and over again how one of the goals of the library is easy interoperability of boost iterators with STL algorithms, but the gotchas seem to be hidden or not mentioned at all. Thanks everyone for the information. -Gabe