Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
From: Nat Goodspeed (nat_at_[hidden])
Date: 2009-02-18 11:48:51

Frank Mori Hess wrote:

>> Nat Goodspeed wrote:

>>> I want my visitor to detect a bound boost::shared_ptr<anything>
>>> and pass the shared_ptr to my new slot_type object's track() method.

>> Frank, couldn't the
>> Signals2 library incorporate that logic itself?

> I don't view the "dynamically replace bound shared_ptr with weak_ptr in 
> incoming bind functor" idea as viable.  

Sigh, yeah -- that would seem to call for a whole new boost::bind() 
feature supporting copy-with-transformation.

> But if you mean the general feature 
> of searching for some base class during connect and automatically tracking 
> those objects, that might get added in the future.  I would do it strictly as 
> an optional extension though, in separate headers and only using the 
> library's existing public interfaces.  It would add a free function findable 
> by ADL that would look for the trackable base class when connecting, 
> something like:
> 
> class shared_trackable: public enable_shared_from_this<shared_trackable>
> {};

If I understand correctly, we expect the coder to pass to boost::bind() 
a plain pointer, a reference or a weak_ptr to a shared_trackable 
subclass instance. None of those will artificially prolong the life of 
that instance. However, using enable_shared_from_this lets your visitor 
obtain a shared_ptr to pass to slot_type::track(). Yes?

It's still the case that if the coder passes to boost::bind() an actual 
shared_ptr to the shared_trackable subclass instance, the 
slot_type::track() mechanism becomes irrelevant because the object won't 
die. That might warrant a note in the documentation for this feature.