Re: Weird behaviour from std::list<>::reverse_iterator
On Aug 26, 2:31 pm, Pete Becker <p...@versatilecoding.com> wrote:
James Kanze wrote:
On Aug 25, 4:13 pm, Pete Becker <p...@versatilecoding.com> wrote:
Rune Allnor wrote:
[...]
So from a semantic point of view, the obvious thing to
try is
std::list<T> list;
std::list<T>::reverse_iterator i = ...;
list.erase(i);
and then expect the item referenced by i to be erased.
Isn't that the philosophy behind the STL? That users
should only worry about semantics and not need to know
about implementation details?
The problem with that, of course, is that list::erase
doesn't take a reverse_iterator, so that code doesn't
compile. You'd have the same problem if you tried to use
any other iterator type (except list::iterator and
list::const_iterator) here. And that's a legitimate
complaint.
Just wondering... Is it too late to do something about this
for the next release of the standard. It doesn't look like
it would require a lot of work.
Iterator adaptors (such as reverse_iterator) work when you
pass them to generic algorithms. Making them work with
non-generic algorithms that make assumptions about details of
the underlying container is quite another thing.
I wasn't thinking of anything so generic. Reverse iterators are
IMHO a special case, because they can be returned by member
functions; they are known to the container.
Off the top of my head, I don't see a clean way to do it.
-- add a requirement that iterator adaptors provide a member
function that returns the underlying iterator. Currently there
are no explicit requirements for iterator adaptors, so someone
would have to define what iterator adaptors are and write a
complete set of requirements for them.
The problem would be to define the "underlying iterator".
reverse_iterator<>::base() returns the underlying iterator, but
it doesn't seem to be what was wanted here.
-- add an ad hoc set of member functions (erase, sort, ...)
to all the container requirements for each of the standard's
iterator adaptors. Gack.
Only for the types of iterators the container can return. If
the container can return iterator, const_iterator,
reverse_iterator and const_reverse_iterator, it seems reasonable
to be able to call erase with any of these, either because of
overloading or implicit conversion.
(And while I'm at it, I note that the change of erase to take a
const_iterator, with, if I read correctly, no overload to take
iterator, breaks code. The cases are probably rare, but still,
it's unnecessary---it would be more reasonable to provide an
overload.)
-- specify a converter function that takes an iterator and
returns its underlying iterator; default is to return its
argument, specialize for various iterator adaptors. Maybe.
Of course, all of these would also have to address the
possibility of an adaptor that's constructed from another
adaptor. And that's not trivial.
The general case is IMHO to complicated to be addressed by the
standard. The only thing that I think might be considered is
requiring overloads for erase, insert and emplace so that they
can be called with any iterator type which is actually known to
the container.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34