On Wed, Jun 3, 2009 at 6:08 PM, Sebastian Theophil 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