Re: [Boost-users] Implementing python's enumerate with iterator adaptors

Subject: Re: [Boost-users] Implementing python's enumerate with iterator adaptors
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-18 03:36:55

On Wed, Apr 18, 2012 at 12:11 AM, Jens Auer <jensa_at_[hidden]> wrote:

> Von: boost-users-bounces_at_[hidden] [mailto:
> boost-users-bounces_at_[hidden]] 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