Why does the g++ 4.0 version of map<T>::erase(map::<T> iterator) not return a iterator?

Question

Hi,

I'm porting a medium-sized C++ project from Visual Studio 2005 to MacOS, XCode / GCC 4.0.

One of the differences I have just stumbled across has to do with erasing an element from a map. In Visual Studio I could erase an element specified by an iterator and assign the return value to the iterator to get the position of the next element. This way the iterator would not point to some invalid address after erasing.

In other words, in Visual Studio I could do this:

itor=m_ResourceMap.erase(itor);

In GCC 4.0, the erase function returns void, so I can't do that. Does that mean that the following map elements are shifted one backwards, so the iterator points automatically to the next element, or does that mean that I have to increment the iterator afterwards? The online STL Documentation is not very concise on the subject and XCode does not seem to have any.

Thanks for your help,

Adrian

Answer 1

No. You have to increment the iterator before erasing. Like this

m_ResourceMap.erase(itor++);

The iterator is invalidated by the erase, so you can't increment it afterwards.

Answer 2

By the look of things gcc is following the STL standard so I guess you'll have to change your code.

void erase(iterator pos)     Associative Container  Erases the element pointed to by pos.

Answer 3

jpalecek: Thanks for your reply! But are you sure there really is a difference between

m_ResourceMap.erase(itor++);

and

m_ResourceMap.erase(itor); ++itor;

In other words, does the postincrement really take place before erase(itor) is executed? This might be an academic question in this case, but I thought that this wasn't the case and it could backfire in other instances (e.g. when calling functions by reference and post-incrementing the argument).

Thanks,

Adrian

Answer 4

I believe that the DinkumWare implementation of the C++ standard library implementation of erase() is defined to return the iterator after the element that is to be removed. This bit me as well and, when I asked DinkumWare about it, they said that it was a "conforming extension".

There are some STL containers (vectors for instance) that, when you perform insert or erase operations, can tend to invalidate all of the iterators for that container. I cannot recall if the map is one of those but, if it is, there is a potentially insidious vulnerability to your method of erasing map elements in a loop.