Boost logo

Boost Users :

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

On Tuesday, February 21, 2012 12:13 PM, Ovanes Markarian wrote:
> On Tue, Feb 21, 2012 at 5:59 PM, Andrew Holden <aholden_at_[hidden]> wrote:
>> 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:
>>>> 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.
> Actually this is what I am trying to prevent in my code. Just do an assertion that
> remove was successful, but finally, I got in the unit test an assertion failure,
> because I was deleting a last element in the ordered index and got end-iterator. And
> my comparison with the end-iterator returned false for removal, resulting in the failed
> assertion.

To clarify, are you saying that, when you deleted the last element in an index, you did *not* get the end iterator? Or are you saying your test considered end iterator an error? To clarify, end iterator from erase never indicates an error. It just means you deleted the last element.

I found an old email from Joaquín Muñoz detailing some macros that enable iterator checking. Maybe this will help you? If I recall correctly, any of the checks these macros enable will cause an assert within the container's member functions. There is still nothing in erase(iterator)'s return value to indicate success or failure.

On 24 September 2009, Joaquín M López Muñoz wrote:
These macros are not documented in the reference for a very academic reason, they're details of this particular implementation rather than part of the public interface --this is admittedly a little too picky, maybe.

The macros are documented through the tutorial, though. For your reference:







Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at