View Full Version : Why boost.signal?

Le Viet Bach
01-10-2011, 04:05 PM
I'm just curious about why boost.signal is used as the signal library.
It has a quite bad reputation about performance.
There are also other alternatives such as sigslot, fastsig or Clanlib's signal.

Also, can frequent addition and removal of components lead to memory fragment and slow down?
How easy is it to hook up my custom memory manager into the system?

Anyway, thanks for sharing such a great framework.

01-10-2011, 11:15 PM
Yes, boost::signals is a snail and I would like to switch to something else.

I can't remember all my reasoning but I think my problem with CL's slots was it will segfault if you delete a slot while you're in it which was something vital. I also looked at Don's "fast delegates" and decided it wouldn't work for a reason I don't remember.

Looking around, it looks like libsigc++ would be fairly easy to switch to (http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html) and give a nice speed bonus. It would even be possible to write a macro that could switch implementations between them I believe... hmmm.

Oh, crap. libsigc++ is LPGL, this puts us in murky legal waters on iOS where dynamic linking and changing out the library isn't possible. (Or has this been legally resolved? Unsure)

About memory fragmentation:

I think most memory managers these days are smart enough that fragmentation caused by many tiny allocations isn't a big problem, at least this has been my experience.

If you had your own memory manager it might be possible to override new/delete with it I guess? Unsure about that but I would probably avoid something like that unless it was for a very specific case such as thousands of game entities, as all the devices p+ targets are pretty beefy these days.