Douglas Gregor wrote:
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.
The complex implementation shouldn't be a bar to it being used. It provides a means of handling all return values as the signal sees fit. I think it is brilliant. It's a slightly complicated issue for the designer of the event and not the event handlers, who just return the appropriate value, and that is how things should be.
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.
I agree that this could be provided with a different general purpose mechanism for determining the order in which signals are called. If I think of anything brilliant myself, or even mildly interesting <g>, I will convey it to you.
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.
Yes, it seems that requiring a class to be derived from a particular class to be trackable might be too much coupling. But it works and should be little problem considering C++'s multiple derivation ability. I can't think of a better way offhand to do it. Somehow the object which contains the slot must tell the signal whether it is still alive or not.
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 don't see how Boost.Signals can or should take into account multi-threading issues, but I am sure you have thought long and hard about this regarding situations of which I have no awareness. I have a gut feeling that multi-threading issues must be solved by either a separate C++ library, like Boost.Threads, or by the language itself, and should not be the domain of every other 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.
I hope you do. C++ needs to move more solidly into the present paradigms of programming, and event handling as a language/library interface has become, at least for me, almost ubiquitous with effective modern day programming practices. Of course I also like the "property" idea, in the property/method/event programming model, but I have found it is fruitless to argue with others about it since the resistance to syntactical sugar, no matter how elegant it may be, is ingrained in most C++ programmers. But events serve a much deeper purpose which makes programming itself much easier and clearer.