I'm trying to write a callback class for my GUI windows. To (hopefully) achieve that, I'm using delegates.
typedef srutil::delegate2<void,DWORD,DWORD> CallbackMethod;
typedef std::map<MESSAGE_TYPE,std::vector<CallbackMethod>> CallbackMap;
MESSAGE_TYPE is an enum.
What I need is some kind of way that automatically unregisters any object from the map when it gets destroyed, via some sort of persistent/constant index, that doesn't rely on modifying the class destructor.
I mean, okay, my planning may be flawed from the ground up (I'm still coding half blind in these advanced things), since I specify the callback to match a certain signature, so in essence any class using this functionality must have some methods matching it, and thus already is kind of forced to abide to those rules (coupled to the class).
So I might just put a reference to the map inside them. That alone, though, would still require iterating over all the entries in the map and removing the ones that match the object being destroyed.
So I guess what I need is some sort of self aware constant reference pointer index thing.
Do such things exist? It feels to me like it should be a common problem...
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:
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!