Re: Weird behaviour from std::list<>::reverse_iterator
James Kanze wrote:
That, on the other hand, could be done. As far as I know, no
one has suggested it, but it would certainly be possible to
overload list<>::erase (and the erase functions in the other
containers) to take a reverse iterator, and that these
overloaded functions encapsulate the necessary logic.
Well, sure. We could add erase member functions that take each of the
standard's iterator adaptors to every container. But that won't help
with user-defined iterator adaptors. It also won't work when someone
wraps a list iterator in a reverse iterator and wraps that in a move
iterator. (I'm not sure that that's legal, but you get the point). This
is an ad hoc solution, not a generic one. It still leaves you having to
read the documentation to understand what the non-generic algorithm does
and what it requires for its non-generic iterators.
Isn't that the philosophy behind the STL?
Not really. The philosophy is generally let the user beware,
with undefined behavior lurking at every (mis)step.
When a program calls list::erase with a reverse iterator the requirement
is clear. list::erase takes an argument of type list::const_iterator, so
the program is ill-formed. No undefined behavior in sight.
The STL philosophy is that iterators work with generic algorithms. Some
containers provide non-generic member functions (such as list::erase,
vector::erase, and list::sort) that work with their own iterators.
Making generic iterators work with non-generic algorithms is not a
trivial extension.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)