Project page |
When programming in C, it's usual to use callback functions (moreover when you do GUI stuffs). In C++, we prefer to encapsulate things into classes, and usually we want a rather type-safety. This small library attempt to provide an easy-to-use, type-safe, C++-friendly solution to the problem. The idea is to define slots, either as global functions or member methods, that will be called when some signals are emitted The signals and slots do not need to really know about each other, only a pointer and a compatible signature is required. Inconsistent connections (when return type or parameters do not match) should be detected at compile-time.
But what all this is about ?
I'm glad you ask, probably you're not familiar with the signal/slot paradigm. So here's a small explaination.
Imagine you're writing a program with a graphical user interface (GUI). The purpose of this program is to compute some nice image, for example some complex fractal, then display it. Most probably, you'll have at least two graphical components : an area where to display the image, and a button called "start". When the user clicks the button, the image is computed in some other part of the program, then displayed when it's finished.
All of this can be accomplished using callbacks, and it's the method used by many GUI toolkits. Forget a little bit the code. The simple structure presented above can be illustrated like this :
When clicked, the button "emits" some kind of signal, which will launch the image computation. When this is finished, some other kind of signal is "emitted", to tell "the image is ready". So the display method can display it. Again, all of this can be done using callbacks.
But generic callbacks often imply passing parameters as void*
pointers, which is, say, not nice. Also, what is you want to add some
function to store the image in a file ? You need to call at least
two functions when the image is computed, which means giving
two callbacks. So you have to create some "callbacks-management"
code.
In the signals/slots paradigm, this is not a problem. The computing part have a slot, used to launch the image computation. Any number of signals can be connected to this slot, so more than one event can cause the image computation. In the same way, this code part has a signal telling others that the image is ready. Any number of slots can be connected to this signal : one slot to display the image, one to save it, for example.
This library attempts to provide a generic signals/slots framework using the C++ language, avoiding the need to do nasty casts by insuring signals and slots can be connected. They can be connected if they have the same complete signature, that is, the same return type, and the same number and types of arguments.
If you've heard about the Qt, libsigc++, Sigslot or boost libraries, or any other I'm not aware of (if this is the case, let me know !), maybe you wonder why yet another signals lib. Here are the main reasons :
Qt's system needs a preprocessor (called moc
, for
Meta-Object Compiler) that will produce additionnal code to enable the
connections and handle the signal emitting ; it's quite simple to use,
but you can't use templates on signal/slot-enabled classes, and
inconsistencies are not detected at compile time but at runtime ;
I found libsig++ a great thing, but a little bit to complex to use, and I dislike some casts done into it ; I also dislike the fact that a function (or method) connected twice will be called twice when emitting the signal ;
Boost is fine, but to use the signals module you also need a rather large part of the whole lib ; there's nothing really wrong with that, I just wanted something smaller – and easier to use ;
It was fun to code, and because I did it, I find SlotSig the simplest signal/slot library available ;-)
I would like here to send a great thanks to those who tried the library, and gave so useful feedback about it. Especially Leopold Palomo Avellaneda, who tried it hard and gave some nice advices from the user's point-of-vue. Thanks Leo !
A changelog is available, because the library evolves, as does everything in the known universe.
All releases are available through these links :
Release |
Date |
File |
md5sum |
---|---|---|---|
1.0.0 | 2006-04-17 | slotsig-1.0.0.tar.bz2 | 420dd16af7a6fca92b0b9cdda55363dd |
0.7 | 2005-12-09 | slotsig-0.7.tar.bz2 | 38795d1b6f2caecad60fb36dedc1f94b |
0.6 | 2004-06-11 | slotsig-0.6.tar.bz2 | dfe9f5d3f17075ec23eb923899ac5f24 |
0.5.1 | 2004-05-23 | slotsig-0.5.1.tar.bz2 | 1bf990adb33c556c67a13df81ff88889 |
0.5 | 2004-05-20 | slotsig-0.5.tar.bz2 | f023d1f88d57e9298fbbd6d3288d2ca3 |
0.4 | 2004-03-23 | slotsig-0.4.tar.bz2 | 877f7da03b247d1c778fc0729269fb60 |
0.3 | 2003-11-22 | slotsig-0.3.tar.bz2 | 06343ee4472b9f56d6b7cf1ba2c9e98d |
0.2 | 2003-06-09 | slotsig-0.2.tar.bz2 | 47d4b9a86020c970142c256769ed7f6c |
0.1 | 2003-06-03 | slotsig-0.1.tar.bz2 | 61d6ff387d0b451035aec7aa1ccb2d24 |
About the two oldest, I guess I should be ashamed...
SlotSig comes with a full set of documentation, which can be read on-line :
There's also a mailing-list about SlotSig, for now mainly used to announce new releases or major new features. So its volume is very low (say, a message every two weeks), and is not expected to grow much.
If you have nice ideas, or pertinent comments about this humble library, you can send me an email at slotsig_AT_kafka-fr_DOT_net (change the _AT_ and the _DOT_ to the letters of the same name).
I would also appreciate to know about you if you're using the library, and what you're doing with it.
Last update 2006-04-17