Boost logo

Boost :

Subject: [boost] [iterator] iterator-category logic
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-18 04:20:29

I'd like to ask Boosters' opinions on this.

boost::iterator_facade determines the iterator_category via the logic
outlined in

In particular, if
(a) CategoryOrTraversal is a Boost traversal tag; and
(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 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?
(b) If so, should iterator_facade's iterator-category logic be reworked to
account for the new requirements?
(c) If so, how should it be determined when to use the C++03 requirements
and when to use the C++11 requirements?


- Jeff

Boost list run by bdawes at, gregod at, cpdaniel at, john at