map.erase( map.end() )?

13,353

Solution 1

end() is not an interator into the map. It's effectively 'one past the end' of the map.

The 'iterator' version wants an iterator to something in the map.
The 'key' version of erase does the lookup and protects itself against key not found, the iterator version assumes you aren't trying to break stuff.

Solution 2

Instead of the example given in a previous post...

MapType::iterator it = the_map.find ("new_key");

// Does not exist.
if (it == the_map.end()) {
  the_map.insert (std::make_pair ("new_key", 10));
}

which does two tree traversals, use...

pair<MapType::iterator, bool> rc = the_map.insert(make_pair("new_key", 0));
if (rc.second)
    rc.first.second = 10;

That way you do one tree traversal and you have the iterator ready to roll for other stuff.

Solution 3

Here is a quick example of how I use the STL map with iterators while removing. I also do the same thing when performing an insert. Personally I like using typedef to specifically define the map, but the choice is yours.


typedef std::map... MapType;

MapType the_map;

MapType::iterator it = the_map.find ("key");
if (it != the_map.end()) {
  // Do something productive.
  the_map.erase (it);
}

MapType::iterator it = the_map.find ("new_key");

// Does not exist.
if (it == the_map.end()) {
  the_map.insert (std::make_pair ("new_key", 10));
}

Hope this helps!

Share:
13,353
Steve Folly
Author by

Steve Folly

Updated on June 06, 2022

Comments

  • Steve Folly
    Steve Folly almost 2 years

    Consider:

    #include <map>
    
    int main()
    {
        std::map< int, int > m;
        m[ 0 ] = 0;
        m[ 1 ] = 1;
    
        m.erase( 0 );  // ok
        m.erase( 2 );  // no-op
        m.erase( m.find( 2 ) );  // boom!
    }
    

    (OK, so the title talks abouting erasing an end() iterator, but find will return end() for a non-existent key.)

    Why is erasing a non-existent key OK, yet erasing end() blows up. I couldn't see any explicit mention of this in the standard?

    I've tried this on VS2005 (throws an exception in debug configuration) and GCC 4.0.1 (100% CPU). Is it implementation dependent?

    Thanks.