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 14:05:10

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

> 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 think I misread or misunderstood English... ;(
"An iterator pointing to the element immediately following the one that was
deleted, or end() if no such element exists."
I considered if no such element exists to be the element the iterator
parameter pointing to, but actually this means the next element succeeding
the deleted one or end, if no succeeding element exists.

> 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

Thanks for the macros I will think enabling them

Regards,
ovanes