Reece Dunn wrote:
The handler is currently defined as boost::signal< bool ( event * ev )
, such that ev is the OS-specific event structure and the return value indicates is the message has been processed (and processing should be stopped). Since the signal has a non-member signature, you need a make_handler( Object * ob, bool ( Object::* h )( event * ev )) helper that constructs a function object that will call the member function.
If you use boost::function<> to specify the event, you do not need a make_handler or any other type of extraneous support. Boost::function<> can serve for any type of function object. The end-user just has to know how to create a boost::function<>, most easily done through boost::bind<>. If you want to make it easy, macro-wise or function-wise for your end-user, sure you can use make_handler or an appropriate macro, but why not let the end-user decide what they want to do. Boost::bind is powerful, so do not take it away from those who want to use it. By using boost::function<> you are providing all the end-user needs for an event handler of any function type. Doing less than that just takes programmers back to the old restrictive ways of MFC, wxWidgets etc. etc. Since Borland with __closures and Microsoft with delegates have already moved on to their own non-standard C++ ways of doing universal function objects, and boost::function is able to do this purely using standard C++, not using seems just another step backward in C++ programming.