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

Subject: Re: [Boost-users] [Multi-Index] Design Rationale behind erase in ordered_index container
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2012-02-21 15:29:18

Ovanes Markarian <om_boost <at> keywallet.com> writes:

> 
> Hello Joaquín,

Hi Ovanes,

> 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.

To be in accordance with the standard. As others have pointed out,
prior versions of the standard incorrectly dictated that for
some containers erase(iterator) return void, but this was later
fixed, see

http://www.boost.org/libs/multi_index/doc/release_notes.html#boost_1_33_1

for details.

> 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.

erase(iterator) never fails if used legally: providing it with an
iterator from another container, which is illegal, results in undefined
behavior. Enabling the safe mode as Andrew suggests can help you *debug*
your problem, but shouldn't be used as a library feature in production
code --safe mode incurs a considerable runtime penalty.

If you really need to call erase(iterator) with iterators from
another container, the solution would be to refactor your code
so as to store pair(iterator,container&)s rather than iterators
and do the check before actually executing erase().

Joaquín M López Muñoz
Telefónica Digital