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:00:45

Please don't top-post.  I've taken the liberty of moving your reply to the bottom where it belongs.

On Tuesday, February 21, 2012 10:33 AM, Etienne Pretorius wrote:
> On 21 Feb 2012, at 5:29 PM, Ovanes Markarian wrote:
>
>
> Hello Joaquín,
>
> the doc states in erase that an iterator or end-iterator is returned when erasing an
> element. What was the rationale behind returning the iterator? Where other members
> return the number of elements being removed.
>
> My point is that end-iterator is also returned when erasing an element where iterator
> points one before the end iterator. Now to be sure that  the specified element was
> really removed my call must either use the key and search for that element again or
> compare the size before and after the erase call.
>
>
> Many thanks,
> Ovanes
>
> http://www.boost.org/doc/libs/1_47_0/libs/multi_index/doc/reference/ord_indices.html#synopsis
> 
> iterator erase(iterator position);
> Requires: position is a valid dereferenceable iterator of the index.
> Effects: Deletes the element pointed to by position.
> Returns: An iterator pointing to the element immediately following the one that was deleted, or end() if no such element exists.
> Complexity: O(D(n)).
> Exception safety: nothrow.
>
> Probably so that you may selectively erase elements within a loop based on some criteria.
>
> Kind Regards,
> Etienne Pretorius

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.

2: Returning the iterator allows programs to easily erase elements without losing their place in the container.

3: The erase function is guaranteed to succeed.