Which C++ signals/slots library should I choose?

Question

I want to use a signals/slots library in a project that doesn't use QT. I have pretty basic requirements:

1. Connect two functions with any number of parameters.
2. Signals can be connected to multiple slots.
3. Manual disconnection of signal/slot connection.
4. Decent performance - the application is frame-based (i.e. not event-based) and I want to use the connections in each frame.

I've read a comparison between libsigc++ and Boost.Signals. I've also read that Boost.Signals suffers from poor performance. However, I know there are other libraries and I'm still not sure which library should I choose.

Are there any recommendations for a signals/slots library?

Answer 1

First, try with boost::signal anyway. Don't assume it will not be fast enough until you try in your specific case that is your application

If it's not efficient enough, maybe something like FastDelegate will suit your needs? (i did'nt try it but heard it was a nice solution in some cases where boost::signal don't seem to suit).

Anyway, if in your application use the signal each frame, it may be worth to replace the signal system by something more simple, like a container that hold objects/functors that will be called each frame. Signal is more made to allow immediate "events" management than to make a loop cycle dynamic (allowing changing the functions called each frame). (I have my own solution (UPDATE: it's very old and archaic now) that i heavily use in a game and for instance i've no problem with the performance, so maybe something similar could help).

Answer 2

Very, very fast event library on Gamedev.net forms

When profiling some code I'd been working on recently, I was surprised and dismayed to see boost::signals functions floating to the top. For those of you who are unaware, boost::signals is a wonderfully useful signal/slot library which can be used alongside boost::bind for delegate-based event handling such as one sees in C#. It is robust, featureful, and flexible. It is also, I have learned, incredibly, terrifyingly slow. For a lot of people who use boost::signals this is fine because they call events very seldom. I was calling several events per frame per object, with predictable results.

So I wrote my own. Slightly less flexible and featureful. It's optimized for how everyone tends to actually use events. And event invocation is fifteen to eighty times faster than boost::signals.

see link

Answer 3

The two you listed are the only two worth while that I'm aware of. Everything that I have seen has shown libsigc++ coming out on top performance wise. As you saw in the comparison, there are some instances where boost's syntax is a little prettier, but just a bit.

I've personally used libsigc++ and am happy with it. Libsigc++ seems to be used by vastly more projects. A quick look in my package manager lists more than 100 projects dependant on libsigc++2. That alone is enough in my opinion to tilt the balance especially considering the performance advantage and the lack of other significant differences.

I say libsigc++2.

Answer 4

Recently inherited a project where connect was producing too much overhead for our project goals. Profiling revealed the use of a mutex in the signal, which was unneeded given our signal usage. Replaced with a dummy mutex per the documentation with success. The mutex is "drastically slower", so be sure you need it. This may be useful for others skimming this post.

Original typedef boost::signals2::signal_type<void()>::type signal_type;

New typedef boost::signals2::signal_type<void(), boost::signals2::keywords::mutex_type<boost::signals2::dummy_mutex> >::type signal_type;

Answer 5

I would vote for Sigslots, I have tried a couple of the other alternatives (boost, libsig++, FastDelegates) and none seemed to do just what I wanted: binding functions together in an anonymous way with automatic on-object-destruction disconnect.

Sigslots was great for us because it is perfectly readable C++, it is fast, simple, and does the job without getting in the way. One minor thing, if you want to use it from several libraries you might need to add:

COREEXTERN template class COREIMPEXP has_slots<SIGSLOT_DEFAULT_MT_POLICY>;

to avoid already-defined-object-related linking issues.

Answer 6

I've used libsigc++ before, and it was pretty straightforward. I don't think it would have much in the way of performance penalties, and indeed I learned to like using slots instead of function pointers in a few places.

One thing to be aware of was that as of the last time I used it (2+ years ago), it was limited to a max of six parameters being passed through the connections.

I don't have any experience with the boost library, so I can't help you there.

Answer 7

I have used boost signals2 library, and it is very slow. On construction of object with boost signals, 99% processor time consumed by boost signals stack. On signals emit with single simle slot also it had very large overhead. I try libsigc++ and it's significantly faster. Libsigc++ seems to be very fast and flexible Creation of 40000 objects with 9 boost signals and 9 libsigc++ signals:

Answer 8

I have not used libsig++ but I've read up on it. My previous experience with signals and slots are from Qt and a little from Boost. If you don't have either of them available then you can try out my own signal and slots library (ksignals) that exist both for embedded code (no dynamic memory allocation) and "normal" c++ code (dynamic memory allocation when connecting).

You can find it at : www.kjellkod.cc/signalandslots

At the the page you can also find a comparison: KSignals Vs Boost signals.

Speed vise ksignals is very fast and extremely lightweight code wise. It should be very easy to use, understand and if needed to modify it.

Good luck Regards Kjell H

Answer 9

One more sig-slot implementation to consider:

http://code.google.com/p/ting/wiki/SignalSlotUsage

It does not pretend to be the best one, but, still, another one which has its right to exist.

Answer 10

An another option can be YSignalSlot. I used it. I think it is pretty good.

Answer 11

What about this alternative implementation that looks good: http://endl.ch/content/fastsig ?