Etienne and Andrew thanks for your comments, please find my answers below... On Tue, Feb 21, 2012 at 5:00 PM, Andrew Holden < aholden@charteroaksystems.com> 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