Re: Weird behaviour from std::list<>::reverse_iterator
On 25 Ago, 12:46, Rune Allnor <all...@tele.ntnu.no> wrote:
On 25 Aug, 11:27, James Kanze <james.ka...@gmail.com> wrote:
On Aug 24, 7:53 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
On 24 Aug, 19:34, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
The semantics is clear: I have used reverse_iterators to work
my way from list.rbegin() to some item in the list. The
semantically simple call
list.erase(middle);
spawns a compiler error.
That's because there's no function list<>::erase which takes a
reverse iterator.
Your misconception is that *middle == *(middle.base()). It
isn't. The reverse iterator's 'base' iterator points to a
different value in the container. At least IME.
That's the opinion of the standard, too. In fact,
reverse_iterator<>::base is guaranteed to point to the element
after (in the original sequence) the one pointed to by the
reverse iterator. The reason for this is simple:
I can see the technical arguments why things are done
like this, but I can't see why these technicalities are
exposed to the users of the STL.
Whenever I, as *user* of the STL, uses a reverse iterator
to search for an item in a container, the natural semantics
of iterators (as a general concept, not C++ type) is to
manipulate the element in the container referenced by that
iterator. Not the element before. Not the element after.
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?
I agree with you, I think that such a detail should be completely
transparent to the final user. Maybe there is some reason for this,
maybe also a reason that _obliges_ to take on such interface design,
but it could be as well an oversight as pointed out by Victor, simply
don't know enough of the STL implementation to dig this issue.
In any case, I'd have expected "erase" to accept a reverse_iterator
too. On the other hand, it is easy to derive from std::list and add
such a feature:
-------
template<class T> class MyList : public std::list<T> {
public:
void erase(typename std::list<T>::reverse_iterator& r_iter)
{
std::list<T>::erase(--r_iter.base());
}
};
-------
With reference to the OP code, changing the following two lines:
-------
std::list<size_t> list;
list.erase(middle.base());
-------
to this
-------
MyList<size_t> list;
list.erase(middle);
-------
lets the code work as intended and give the expected results.
Disclaimer: easy on my template derivation, I've just added as much as
needed to let the code compile and work. A serious derivation should
take allocators in account, and the "erase" function I added should
return a reverse iterator on its turn, to be coherent to the existing
one that works on forward iterators. I'm not on firm ground doing such
things, that was just a pointer. Better coders can improve it.
Hope that helps,
have fun,
Francesco