On Tuesday 26 August 2003 05:41 pm, Edward Diener wrote:
Is there a reason Boost.Signals wasn't submitted for TR1 approval other than the worked involved doing so by writing up the necessary submittal form ?
Yes, there's a reason: Signals isn't ready for standardization. It hasn't been around long enough for us to be sure we have the right interface, nor is it small enough that we can say "yep, that's the right interface." More specifically, there are some parts of the interface that I don't believe are entirely correct, including: 1) Combiners and the slot_call_iterator: I think the interface is correct (although the implementation is very complex), but we can't say for sure that it was worth the effort. 2) Slot ordering, groups, and naming: I'm pretty sure we have this wrong, but I don't know what's better. Most applications could do with a simple linked list of slots, that are called in the order they are connected; a few more apps would benefit from the ability to connect to the front or back of the list; but there don't seem to be many apps that actually need the ordering & naming that Signals provides. 3) Trackability: there's a general tracking interface here that would be really useful, but I haven't had the time to pull it out. 4) Multithreading: this isn't much of a concern for the standard right now, but without a solid multithreaded implementation I don't want to try to standardize the interface for fear that it may not allow a good multithreaded implementation.
I would very much like to see the C++ standard library adopt a common event handling interface, whether through a library such as yours or an extension to the language ( such as Borland's __closure pointer ). Handling events in a common way, and especially allowing both events and handlers ( signals and slots ) to be free of specific class limitations, will move C++ much closer to a modern paradigm which I find invaluable in using the language.
I agree that it would be very useful to have a common event handling interface, although I firmly believe it should come in the form of a library and not via a language extension. I'll be happy to propose Signals when I think we've hammered out the existing problems. Doug