Boost logo

Boost Users :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-08-26 19:53:23

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

> 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.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at