On Wed, Apr 18, 2012 at 12:11 AM, Jens Auer
Von: boost-users-bounces@lists.boost.org [mailto: boost-users-bounces@lists.boost.org] Im Auftrag von Jeffrey Lee Hellrung, Jr. 1> My guess is this is where that proxy reference bites you, as it makes your Enumerator iterator not strictly a random access iterator, even though it morally is, so boost::iterator_facade won't set your 1> iterator_category to std::random_access_iterator_tag and instead tries to go a middle-of-the-road approach (IIRC). Try typedef'ing 1> 1> typedef std::random_access_iterator_tag iterator_category; // I think this is right... 1> 1> in your Enumerator definition and see if MSVC complains?
Hi Jeff,
this fixed the problem and now it compiles, although I would prefer typedef typename Iterator::iterator_category iterator_category;
to make the Enumerator the same category as the underlying iterator.
Yes, you are correct, that would be more general (actually, you would use std::iterator_traits< Iterator >::iterator_category rather than Iterator::iterator_category, to be precise). It's just if you grab the iterator_category from boost::iterator_adaptor, you'll lose strict random access due to the reference type being a proxy. Indeed, the most robust solution for your use case would probably be to use some metaprogramming logic to determine the iterator_category similar to that outlined in boost::iterator_facade, but which doesn't see a proxy reference as immediately knocking down the iterator_category to std::input_iterator_tag or whatever. So, in C++03, you'd technically be lying to your standard library implementation if you say your iterator_category is random access but you have proxy references, since *i is suppose to a "real" reference. However, my draft of the C++11 standard seems to have dropped this requirement, indicating that you're safe, at least on standard library implementations that follow the C++11 iterator requirements as opposed to the C++03 iterator requirements (and I don't know where the version of MSVC you're using stands in this regard). In any case, I think I'll raise this issue on the developers' list... - Jeff