
Hehe it is: http://www.boost.org/doc/libs/1_47_0/doc/html/boost/signals/trackable.html
Ah, so I should provide appropriate visit_each() overload for my callback type? Can't say I understand what it is suppose to do tho. Example for Boost.Function would be great ;)
Signals2 requires objects to be managed by shared_ptr which imho is more intrusive (in a sense of class design enforcement) than original Signals. My objects are kept in ptr_ and intrusive containers and it is trivial to make
Sorry, I probably misunderstood you. I also don't quite understand what the documentation means by saying "User-defined function objects<...>do not implement the required interfaces for trackable object detection". Any user-defined object can inherit from signals::trackable and thus "implement the required interfaces". boost::function (and of course, std::function etc) really doesn't provide such a functionality as far as I know, and I'm not sure it's possible to add it externally. them trackable but impossible to make them being managed by shared_ptr. If your objects have to be managed by other types of smart-ptrs, you still can use weak_ptr for tracking: struct your_class { your_class() : track_(new int()) {} private: shared_ptr<void> track_; } ...now pass track_ for any tracking purposes. If you've got a single-threaded design it seems to be safe, doesn't it.
Additionally, within specific sub-systems signal-slot connections are single-threaded and using: namespace bs2 = boost::signals2; using bs2::keywords; bs2::signal_type
bs2::dummy_mutex >::type sig; instead of: signal sig; especially multiple times in single class definition is just horrible. Or am I missing some easy way to redefine default mutex?
Well... at least, you can typedef mutex_typebs2::dummy_mutex :).