From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-04-04 08:52:46
Sorry, I don't have many comments on the code itself, mainly on the concepts
Let me start off by showing my ignorance. I am not really familiar with the
concept of signal and slot.
I found the Qt documentation about it and it sheds a little more light.
It would help clarify your explanation if you noted the strengths and
inadequacies of the Qt approach (like the fact that it seems to need a
special compiler is a *major* drawback). And then comment on how your
approach builds on the strengths and addresses the inadequacies.
I have a hard time thinking up some good examples. Some code and narrative
explanation might help to clarify.
It may just be my unfamiliarity with signals and slots, but I question
whether something that is based on callbacks is the right idiom to promote
By the way, I think that (Qt's) choice of the term "signal" was a poor one.
> -----Original Message-----
> From: tomasz_at_[hidden] [mailto:tomasz_at_[hidden]]On
> Behalf Of Tomasz Kowalczyk
> Sent: Tuesday, April 04, 2000 8:09 AM
> To: boost_at_[hidden]
> Subject: [boost] SUBMISSION: Signal/slot library
> Dear Boost Members,
> I have written a library which deals with so-called signal/slot
> connections. I would like to ask you for review and comments. Since
> boost libraries contain lots of beautiful work, I thought it would be
> the best place to have my own code criticized.
> The source can be found in:
> and a short introduction:
> Although the library is far from complete, I decided to post
> it because
> I believe the techniques employed are very powerful and extremely
> useful, especially in event-driven environments (such as most GUI
> toolkits). I hope to find here new ideas, advice, and maybe gain some
> interest in the further development.
> The library you can find in the above URL was a side product of an
> OpenGL-based viewer for 3D geometry. That's why the
> abstractions may not
> be as general as they could be (this is especially true for slots and
> and connection predicates).
> Please let me explain in a few words what the whole signal idea is
> about, as I can see it now.
> Say you have an class template called signal. For example:
> signal<A,B> sig; // equivalent to a function void sig(A,B)
> where A and B are some types. You may store in this signal some
> lambda-expressions for further use:
> sig.connect( <lambda-expression-1> );
> sig.connect( <lambda-expression-2> );
> Some time later in a different place you can execute all previously
> stored code with your choice of arguments:
> sig( a, b );
> Note the difference when compared to usage of lambda expressions in
> algorithms, such as std::for_each, where the expressions are composed
> and executed immediately. Signals are capable to delay the execution
> until requested.
> GUI toolkits use the mentioned mechanisms to manage notification
> callbacks. However, it is very likely that there exist other potential
> applications than just callbacks (I am hoping to find some
> ideas in this
> list :)
> The library provides also another kind of signal, which I call a
> delegate. It can store only one expression, but in turn can return
> values (returned from that expression). I find it convenient
> to think of
> delegates as virtual functions, which implementation can be
> bound at run
> time. For example:
> delegate<void,char> put; // equivalent to void put(char)
> put.connect( closure( &cout, &cout.put ) );
> put('a'); // a printed to cout
> put.connect( function(fputc) );
> put('a'); // a printed to stdout
> Delegates can be used as a way to achieve non-intrusive polymorphism,
> because implementation can be provided by completely unrelated code.
> As the next step, I am currently thinking about adaptation of the
> signals to be able to use boost's lambda-calculus library, instead of
> the limited choice of slot classes.
> I hope you will like it :)
> Thank you
> Save up to 54% on Quest & Kelty tents, backpacks, sleeping bags and
> outdoor gear. FREE Shipping and a 30 Day Money-Back Guarantee at
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk