Re: [boost] [iterator] iterator-category logic

Subject: Re: [boost] [iterator] iterator-category logic
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-04-18 12:05:44

Jeff,

On Wed, Apr 18, 2012 at 2:20 AM, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:
> (b) Reference is not a "real" C++ reference (i.e., a proxy reference);
> then iterator_category is at best convertible to std::input_iterator_tag.
> This ends up being surprising to users who use boost::iterator_adaptor
> (note that, by default, iterator_adaptor passes the Boost traversal tag of
> the adapted iterator down to iterator_facade) to adapt, say, a pointer,
> define their adapted iterator to return a proxy reference, and find out
> that their standard library functions don't recognize their adapted
> iterator as a random access iterator. The usual workaround tends to be to
> just override the iterator_facade logic yourself to use a more refined
> iterator_category and hope your standard library functions don't barf.

For what it's worth, a recent thread indicated that VC10 standard
library was being non-conformant in requiring that [1].

> For better or for worse, the present logic in iterator_facade is strictly
> (more or less) correct given the C++03 iterator requirements, but I just
> looked up the N3290 draft of C++11 and it appears that any requirements
> that *i return a real reference have been dropped, thus allowing for proxy
> references in all iterator categories.
> (a) Am I interpreting the C++11 iterator requirements correctly?
The changes seemed subtle to me, and I'm not adept at reading
standardese, but that was my reading too.

> (b) If so, should iterator_facade's iterator-category logic be reworked to
> account for the new requirements?
I would like to see that. . .

> (c) If so, how should it be determined when to use the C++03 requirements
> and when to use the C++11 requirements?
My initial thought was that it should be based on the standard library
-- if it assumes iterator_traits<T>::reference ==
iterator_traits<T>::value_type&, then 03 requirements should be used.

However, considering that user code could also have correctly assumed
the same in 03, perhaps a very long, macro-controlled deprecation
period is the right thing to do.

[1] http://lists.boost.org/Archives/boost/2012/01/189715.php

Thanks,
Nate