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