1

When using Boost.Signals, boost allows you to derive from boost::signals::trackable in order to ease object/connection lifetime management (See the boost documentation).

I am in an early stage of my project and I am thinking, whether to derive from boost::signals::trackable in

  • every new class I write that might use Boost.Signals in the future
  • or only in classes I am sure that they will need the functionality of the trackable bas e-class

The main reason for th first approach would be to prevent me to forget deriving from boost::signals::trackable.

Also double deriverations like

class Foo : public Base, public boost::signals::trackable
{
};

get unnecessary.

On the other side, preventing memory-leaks shouldn't be a main design-aspect. Testing and profiling tools like valgrind should be used to detect memory leaks.

Which approach is more suitable for growing projects?

Random Citizen
  • 1,272
  • 3
  • 14
  • 28
  • 1
    If you are worried, maybe write a set of functions that you always use to connect signals/slots instead of directly using signal::connect that has a static assertion in it that the class must be derived from boost::signals::trackable. Maybe boost signals offers a way of doing this anyway. That way, if you forget, your project won't compile. – Pete May 30 '13 at 23:43
  • 1
    Why don't you use `Boost.Signals2`, which has much more flexible and powerful tracking mechanism? – Igor R. Jun 02 '13 at 08:25
  • @IgorR. I haven't taken a look at Boost.Signals2 because I though the multithreading support would slow down my application. But after having taken a look at the [connection Management](http://www.boost.org/doc/libs/1_49_0/doc/html/signals2/tutorial.html#id3151565) I am going to use `Boost.Signals2`. Thanks! – Random Citizen Jun 02 '13 at 11:41
  • @Random Citizen you can even disable locking by changing MutexType ty dummy_mutex: http://www.boost.org/doc/libs/1_53_0/doc/html/signals2/tutorial.html#signals2.tutorial.signal-mutex-template-parameter – Igor R. Jun 02 '13 at 14:43
  • @IgorR. Thanks for your help. Maybe it would be a good idea to post your answer as an official answer? – Random Citizen Jun 02 '13 at 15:49

2 Answers2

3

Note that Boost.Signals2 supersedes Boost.Signals. It has much more flexible and powerful tracking mechanism.

Although the library aims to provide a thread-safe solution for multi-threaded programs, the locking overhead can be avoided in a single-threaded environment by setting boost::signals2::dummy_mutex as signal's internal mutex.

Igor R.
  • 14,716
  • 2
  • 49
  • 83
1

Qt as an alternative

The Qt-Event system enforces programmer to derive from QObject so you really are on the save side when using Qt-Events.

Random Citizen
  • 1,272
  • 3
  • 14
  • 28