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: Ovanes Markarian (om_boost_at_[hidden])
Date: 2012-02-21 11:40:20

Etienne and Andrew thanks for your comments, please find my answers below...

On Tue, Feb 21, 2012 at 5:00 PM, Andrew Holden <
aholden_at_[hidden]> wrote:

> 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.
> >[...]
> >
> > Probably so that you may selectively erase elements within a loop based
> on some criteria.
> >
>
> 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.

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

Thanks,
Ovanes