Is there a reason you can't register the camera function as a listener directly? I.e.dispatcher.register(std::function<void()>(std::bind(Camera::moveLeft, this)), event::CAM_MOVE_LEFT);
I don't know. What happens when the camera dies? How does the dispatcher know to unregister that dangly pointer? Seems like this just moves that responsibility to the camera object, which then needs to be reimplemented for every game object that registers functions to the dispatcher. Unless I am misunderstanding.
Don't allow the object to be copied or moved. These kinds of delegate-like callback systems kind of rely on having immovable objects.
How do you handle storing the objects (like the camera) in a container (std::vector or similar). Doesn't that require a copy?
The other option is to just not use the delegate-like callback model. I find they work especially poorly for input anyway once you get to non-trivial games and game UIs (e.g., layering of menus, interrupted inputs, loss of window focus, etc.) as gameplay often has to deal with interaction models that are very very different from the traditional desktop models where delegates work well.
What is the alternative?
Are you saying that the entire Input->MapToActionsWithAContext->ActOnThoseActions model doesn't work well?
Or are you saying that the final step of resolving the action via callback does not work well?
How else does the game object act upon the action event?
Thanks to both of you.