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