Basically, the idea is that when the buttons clicked on (in addition to whatever other future functionality I add), they call an internal onClicked() function. The idea was to have that onClicked() function call an external function (generally from an external unrelated class) to handle whatever logic is associated with that button (say, Quit, for example). This seems fairly straight-forward with function pointers (e.g., something like typedef void (*funcPtr)(int, double) and yet I keep reading that 'function pointers are bad in C++ and should only be used for legacy code'.
Think about that approach for a second. Don't you think you are handling the function information at the wrong level? In other words abstract it out by one more level and you will have a system that works. You don't need function pointers per se....you need an object that can handle calls to an object of type T for any message M where T could be an interface which has a function that can handle all calls to the object. You can actually accomplish the entire system without using function pointers at all. Who better to resolve the final function call than the object itself? No casting required and no function pointers. If you try to resolve the function calls outside of the object then you have all sorts of nasty and slow casting. Take a step back and maybe even UML your code or design and you will see at least a few ways to overcome this issue without using function pointers.