Re: [Boost-users] [Multi-Index] Design Rationale behind erase inordered_index container

On Tuesday, February 21, 2012 11:40 AM, Ovanes Markarian wrote:

On Tue, Feb 21, 2012 at 5:00 PM, Andrew Holden wrote:

...

I can think of three reasons for this behavior:

1: multi_index mimics the behavior of STL containers to the greatest extent possible, and their erase(iterator) functions return the iterator of the following element. Which ones? std::map<...>::erase either returns void or number of deleted elements.

Hmm. It appears I shouldn't have been using the Microsoft documentation. Microsoft claims the variants that take 1 or 2 iterators return the iterator for the following element.

...

2: Returning the iterator allows programs to easily erase elements without losing their place in the container. Yes this is a good point, it might be possible to return a pair type containing the iterator and bool value.  

...

3: The erase function is guaranteed to succeed. What happens if some sw part mixes up the iterator from the other container instance? This might really be a clear case for assert, if the iterator and container know about each other...

That would result in undefined behavior. If the iterator and container know about each other (usually via a gross violation of big-O), then an assert is possible. Otherwise, expect corruption of your containers, hopefully followed by a core dump.