Boost logo

Boost Users :

Subject: Re: [Boost-users] [Multi-Index] Design Rationale behind erase inordered_index container
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2012-02-21 12:12:38


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.



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net