...

1) What is the required interface for user-defined callbacks?

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 ;)

...

2) Is it still true that it will be addressed in future versions of Boost.Function?

You've got now Signals2, which allows using weak_ptr for tracking purposes.

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 them trackable but impossible to make them being managed by shared_ptr. Additionally, within specific sub-systems signal-slot connections are single-threaded and using: namespace bs2 = boost::signals2; using bs2::keywords; bs2::signal_typebs2::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? Cheers, Simon

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.

Yup, it is about something different. Mind that signal does not store pointers to signalled objects directly. It stores slots which are bound to such object. The way Signals are implemented this works correctly: class Trackable : public signals::trackable { void foo() {} } signal sig; Trackable t; sig.connect(bind(&Trackable::foo, &b)); // this does not work tho: // boost::function func = bind(&Trackable::foo, &t); // sig.connect(func) sig(); even tho sig stores function object returned from bind which is obviously not derived from trackable but only keeps a (smart)pointer to trackable object. Docs clearly state this: "At this time there is a significant limitation to the use of trackable objects in making slot connections: function objects built using Boost.Bind are understood, such that pointers or references to trackable objects passed to boost::bind will be found and tracked." So it is in fact NOT enough to derive from trackable class but also a callback type must be "understood" / "implement the required interfaces".

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_; }

Yeah, that is what I just love about libraries designed in this way, to be able to use it, dummy shared_ptr member must be added to class definition even tho it does not actually share anything. Enforcing memory model is bad but what is worst in this design imho is that instead of just making new class trackable (implementation detail) with Signals2 tracking must be explicit at sig.connect() site, so what works with Signals1 is broken with Signals2: void Foo::func() { connectMe(bind(&Foo:func, this)); } void template <class Slot> void connectMe(Slot slot) { sig.connect(slot); // if sig is Signal1 signal automatic tracking will work if class Foo // is derived from trackable (as binders from bind() and recognized) // but there is no way of making original object trackable with Signals2 // as there is no shared_ptr to pass anymore }

Well... at least, you can typedef mutex_typebs2::dummy_mutex :).

And get 1 more line to write, no thanks ;) Cheers

signals2 does provide a trackable base class that is used the same way as the trackable base class in the original library.  Disconnection by base class cannot be made thread safe in the general case however, since the base class destructor does not run until after the derived class destructor has already run.

Then why would I use Signals2 in the first place? ;) I would just like to understand how to make custom callback type or just even Boost.Function in combination with trackable work with Signals. Cheers, Simon