Sebastian Theophil wrote:
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.
That's what I find hard to assume: how is it permissible to destroy a CObject at any time when its refcount is not zero? If you have some object whose lifetime is managed by boost::shared_ptr, I think it is a bad idea to mess with the object lifetime directly. Please note this is not a rhetoric question: how do you know when you explicitly destroy a CObject that you leave no dangling boost::shared_ptrs to it?
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) }
The latter is the way the lib currently works. Are you experiencing otherwise? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -- View this message in context: http://www.nabble.com/-multi-index--Container-not-safe-against-reentrant-cle... Sent from the Boost - Users mailing list archive at Nabble.com.