Hi Joaquin, thanks for your prompt reply.
If I'm understanding this right, I think your design is flawed. You
say
that CObjects detach themselves from g_multiindex when their refcount drops to 0, but: how can this count be zero if the CObject is still referenced from g_multiindex?
It seems I haven't expressed myself very clearly. Of course, the refcount only drops to zero when g_multiindex is cleared. But assume that a CObject can also be explicitly destroyed at any time. Obviously, before destroying the CObject, the caller could explicitly remove the CObject from the multi_index_container. This would need to be done whenever a CObject is destroyed and sooner or later someone will forget to do it. It seems much simpler to let the CObject dtor do the work of removing all references to itself, as long as the container is safe against "double deletion".
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 delete_node( node* x ) { // container has n nodes destroy(x) // container still has n nodes but x has been destroyed reset left / right / parent pointers // container has n-1 nodes } Or is that wrong? What I'd like is something like delete_node( node* x ) { reset left / right / parent pointers // container has n-1 nodes, x has not been destructed yet destroy(x) } In this implementation, the multi_index_container is never in an invalid state. In the current implementation, elements contained in a container cannot reliably make operations on the same container inside their destructor. The dtor may e.g. destroy the internal data structures used to order the nodes. What if one node's dtor would like to remove a set of dependent elements from the container as well? Regards, Sebastian -- Sebastian Theophil . stheophil@think-cell.com Software Engineer think-cell Software GmbH . Invalidenstr. 34 . 10115 Berlin, Germany http://www.think-cell.com . phone +49-30-666473-10 . toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl . Amtsgericht Berlin-Charlottenburg, HRB 85229