You code is a delegate in C++ with fixed function parameter list. Delegates aren't supported in C++ unfortunately and there are no good solutions to this problem. The two biggest problem with c++ delegates:
- With a single template you can not handle variable number of function parameters.
- The lifetime of the object pointer is independent from the lifetime of your delegate object, so the pointer inside can become invalid. A weakref or strongref is a bit better than a normal C++ ref. This isn't an issue in a language with garbage collector + strong refs.
You are right, you can;t escape dirty coding, but a template is as elegant as u can get. I think this concept can be extended with some more concepts for better lifetime maintenance of the insider object.
If I have to use ugly library then I create a facade - a class that shows a nice interface to me and has the cr@p inside. In this case I don't mind member pointers inside but its rare to see member pointers even in the ugliest libraries outside.
Unfortunately I cant recall a situation where your code makes a big enough difference because of the rarity of member pointers. If I want to call a method with member pointer like you did, then I can wrap this call inside a method of my facade class, no need for template magic here.
I have seen member pointers with reason only in event handlers (UI code - I usually use weak pointed listeners instead), and in a serialization framework where the framework stored the data member offsets as member pointers. Usually when some libraries use member pointers the situation becomes ugly when they start to cast the member pointer and when it comes to crossplatform - for example in gcc a member pointer is 4 bytes or 8 bytes if the class has multiple inheritance somewhere in the hierarchy. The resulting code becomes the hardest to maintain mess.
Take this situatio - CGridCtrl class provides some in built column sorting fuctions and depending upon situations you want to invoke them to sort columns.Again a CGridCtrl derived CTreeGridCtrl class may need to invoke them as well. So, in this case the tip might b a better workaround than introducing a facade.
that's the thing, the CGridCtrl class is a lib or a legacy code... this is just an example, not necessarily i faced this issue in my own project; rather i a m giving an example of a situation where u might find the concept of the tip useful.
Well, this is also a problem where you can set the sort method member pointer to a fix method, and that method then uses an interface pointer you provide. After this you don't have to mess with member pointers.
Well, actually I don't exactly know the class and the problem but I hardly believe it cant be solved without hiding the method pointers from your own code. If you have a fixed number of methods inside the class, then you can define an enum for it and set that from your code and if the sort methods are in the same class then the pointer inside your delegate is needless because every sorting call will come from the same object so you will have a this pointer from somewhere. If I haven't misinterpreted the situation then all you need is an enum in the class that has a member for each sort method plus a set method that changes this enum. Maybe this same set method could store and change a method pointer instead of the enum itself.
I don't understand ur concern abt variable names, of-course the proper name wud b given by the programmer in a real world project, my given names are just place holders and only for this example. Here the elegance lies in the C# like delegate style of invoking method pointers, hiding the intricacies of method pointer invokation inside a class.Ok it is not exactly like a delegate but similar and the concept can b extended and put to good use by some.
Well that is the thing, it's not an article. It is Tips'n Tricks. It is not supposed to explain but to show you a trick. If you don't understand it, you go looking for an article that explains function pointers in C++.
Shall I downvote or dismiss most of the science just because I don't understand ...