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

BOOST_MULTI_INDEX_ENABLE_SAFE_MODE
BOOST_MULTI_INDEX_SAFE_MODE_ASSERT
  http://www.boost.org/libs/multi_index/doc/tutorial/debug.html#safe_mode

BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING
BOOST_MULTI_INDEX_INVARIANT_ASSERT
  
http://www.boost.org/libs/multi_index/doc/tutorial/debug.html#invariant_check

BOOST_MULTI_INDEX_DISABLE_SERIALIZATION
  
http://www.boost.org/libs/multi_index/doc/tutorial/creation.html#serialization

BOOST_MULTI_INDEX_DISABLE_COMPRESSED_ORDERED_INDEX_NODES
  
http://www.boost.org/libs/multi_index/doc/tutorial/indices.html#ordered_node_compression

BOOST_MULTI_INDEX_LIMIT_INDEXED_BY_SIZE
BOOST_MULTI_INDEX_LIMIT_TAG_SIZE
  
http://www.boost.org/libs/multi_index/doc/compiler_specifics.html#symbol_reduction

HTH,

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