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

Subject: Re: [Boost-users] [Multi-Index] Design Rationale behind erase inordered_index container
From: Andrew Holden (aholden_at_[hidden])
Date: 2012-02-21 11:59:07

On Tuesday, February 21, 2012 11:40 AM, Ovanes Markarian wrote:
> On Tue, Feb 21, 2012 at 5:00 PM, Andrew Holden <aholden_at_[hidden]> 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.