On Wed, Jun 3, 2009 at 6:08 PM, Sebastian Theophil <stheophil@think-cell.com> wrote:

> This is simply an uncovered situation, and, IMHO, a very unusual one
> --in support
> of my view I can say I never got a report on this, and the lib's been
> around for
> 4.5 years.

I can't argue against that :-)

>
> On the other hand, erasing inside erase() does work;

What I do is erase() -> ~node() -> erase() and I would guess that
doesn't work for the same reason as before:
If the container has n elements, node deletion goes through the
following states

Sebastian, IMO you should reconsider the design, since you introduced a cyclic dependency in your code.
Even if you fix that, this code will remain fragile and will likely break soon on some other place.

May be my post is not very productive, but to complex logical constructs lead to fragile code. Try to choose one
path on how it might work and implement this contract only. Don't try to decide to much for your users especially
if your code is a low level abstraction which does not have the information on how it might be used. You will not
be able to cover all the use cases by writing intelligent code. You can only restrict your code to work in proposed manner
and no more. Try to apply SRP to the CObject class. What happens if someone put's your CObject to a local vector instead
of global MI-container, this will still try to delete itself from the global MI-Container?

I definitely know very little about the whole app, to make such critics and apologize for that. It is also not the usual in this mailing
list and might even be against the policy of that list.

With Kind Regards,
Ovanes