shyamemani wrote:
So combining this response with your response to Edward regarding standardization of boost.signal, shouldn't this be a big concern, since the use-case which I illustrated is quite commonly used in event based systems?
No, it is not common to want to have a single event handler for events with different signatures. Or to register different event handlers for separate events all with one call. What you are doing is saying that you have these needs, and because a library doesn't fulfill them for you, let's have a language extension to solve your special case. The normal event-handler paradigm is that: 1) a single event handler handles a single event 2) an event may have more than one event handler 3) an event handler may handle more than one event, if and only if, the signature for the event handler is exactly the same for different events and there is a way of telling which one of the events has occurred in the event handler. When you want to go outside this basic paradigm, it is up to you to write code to do so, not for libraries to change merely to accomodate your needs. That doesn't mean you can't suggest additions to libraries which you feel are in the realm of event handling, but you must justify them as being worthwhile not just for you but for programmers in general. Or else create your own library to solve your own problem and perhaps others.
But if this can be ironed out I think providing it as a language extension is better because then C++ can become a language which has built-in semantics for use of the standard design patterns. And then we programmar's and designers can live happily ever after ....
Built-in semantics can be just as limiting, for your needs, as a library and provide no guarantee of happiness. In general, in a case where both a library and a language extension can provide the same solution to some programming paradigm in C++, the most important case for a language addition is, IMHO, ease of programming use. In general it is much better, because more flexible, to extend a language via libraries than adding language extensions. With all that said, having used a language extension for many years which provides event handling to C++, Borland's __closure, and most recently Microsoft's __event and __delegate extensions, I am very much for either adding Mr. Gregor's excellent Boost.Signals in some close form to the C++ standard library, or adding a language extension patterned after the Microsoft and/or Borland solutions to the C++ standard language. However, none of these solve your particular event programming model which I find a very weird and overly complicated design. There is no need in a good event-handler model, such as Boost.Signals, for handlers to derive from a class which represents the events to be handled. Nor do events to be handled need to be virtual. If you take a look at Boost.Signals, and study how it works, you will see that the event and the event handler are only dependent on the signature of the event to be handled, and nothing else really. As long as you have an appropriate signature to handle the event, you can bind to it with any appropriate handler, most particularly member functions of any object's class. I don't think you appreciate yet why this model is so superior to yours as far as ease of use is concerned. The whole idea of a good event-handler model is that the event be coupled as lightly as possible to the event's handlers. This is what Mr. Gregor achieves in his library and also what the Borland and Microsoft extensions also achieve in their own different ways. There is no need to enforce particular derivations or virtual functions in these models.