Off the top of my head, I'm gonna guess... no, it doesn't exists (at least, not for C++).
Your proposal implies a complex situation (even if you weren't using the callbacks). You're asking for something which, upon its own destruction, takes care of removing any reference of itself from (potentially) any data structure which references it. That's a pretty tall order, and is especially not something the STL was meant to do.
If you really want to do this (and I'm sure you do), then here's my initial thoughts. Every time your object gets added to a data structure, you could require that the data structure is registered with the object, e.g. using a method like Object::Register(const std::vector<Object> &v). You can then store the reference (actually, you'd probably capture a pointer) to the vector, so you can tell that vector to remove the object upon destruction. Of course, this has two problems:
- It's still crazy complex (especially if you want to support more structures than just vectors, and even more so if you are looking for an entirely general solution).
- It requires other coder to follow this style everywhere an object is added to a structure
- It would probably require editing the destructor of the
Object, which you explicitly told us it shouldn't do.
So, yeah, not much help there.
Personally, I have a much more preferred solution that revolves around events (specifically, delegate-based event, like what we use in c#). If you're not familiar with how these works, you might like to read this programming guide. Then again, you might not, since we are using c++, not c#, and since I'll pretty much describe it myself.
One reason I like the event idea is that you are already using callbacks. Delegates (as in c# delegates) are just an extension of callbacks. They basically encapsulate the vector<Callback> behaviour in a Delegate class. The Delegate class allows calling all these methods with one operation, if you overload the function call operator. Also, like the delegate you are already using, it would likely be a parameterized type. (In fact, when C++0x is all ready-to-go, which is soon-ish, variadic templates would also be quite helpful).
Anyhoo, the point of all this is that you would be able to have such a Delegate as a member variable of any of your classes:
class Object
{
public:
... // whatever constructors, etc. you might need
Delegate<void, Collection, EventArgs> destroyHandler;
... // and number of event handlers can be used.
};
Now, any data structure class can register a callback by something like:
obj.destroyHandler += myDelegate;
where myDelegate is any function with the necessary type.
This approach has more problems, though. Specifically, it requires a whole new library filled with data structures which are aware of your event model. This shouldn't really be that hard, since the existing STL containers could simply wrapped. It would just be a lot of work, and everyone would have to decide to use your new library.
Another gotcha is found in the line Delegate<void, Collection, EventArgs> destroyHandler;. What do each of these type parameters mean? Well, void should be pretty clear: it's just the return type of the methods. Also, EventArgs are simple: it simply wraps whatever data needs to be passed to the callbacks. The Collection type is the strangest - why to we parameterize the type collection used?
It's to circumvent the nastiness of using pointer-to-member-functions in c++. While such pointers are possible, they're awful to use, and (as far as I know) there is no way to take pointer-to-member-functions from multiple types and store them in a single collection.
Instead, what I have tried in the past (though I didn't really finish the idea) was something like
class MyVector
{
static void DestructionHandler( MyVector & v, EventArgs & args )
{
// ... Handler code goes here
}
};
The thing to note is the parameter MyVector & v: it replaces the usual this pointer. Also, note that the method is static - this allows it to be used as a regular old C-style function-pointer.
Anyways, I might of gotten a little carried away, but when you put all this together, you can get a pretty decent event-based system, which is quite popular in other OOP languages. Besides, I told you it was a tall order!
