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

Frank Mori Hess wrote:

> On Tuesday 17 February 2009, Nat Goodspeed wrote:

>> I can in fact detect a bound shared_ptr and pass it to track() as I
>> want. The problem is that binding a shared_ptr captures a copy, so the
>> referenced object will live until the connection is explicitly
>> disconnected! That makes the slot_type::track() mechanism moot.
>>
>> It looks as though I could only achieve what I want if my visit_each()
>> visitor could *modify* the boost::bind object to replace the bound
>> shared_ptr with its wrapped plain pointer. I don't believe this is
>> possible?

> Wouldn't it be better just to make your visitor just detect a bound shared_ptr 
> to Trackable and report it, forcing the calling code to get it right?  You 
> could use BOOST_STATIC_ASSERT to give a compile-time error, for example.

I'm sorry, I didn't express myself clearly. There are actually several 
different cases:

1. visitor discovers plain pointer/reference to a subclass of my 
Trackable base class:

Use Trackable to track the new connection.

This is working now -- but as you point out, it's less safe than your 
slot_type::track() mechanism since a Trackable might be destroyed during 
a slot call.

2. visitor discovers a shared_ptr to something other than a Trackable 
subclass:

This is the case I was asking about. My visitor can in fact pass the 
shared_ptr to slot_type::track(), but it's pointless because the 
shared_ptr copy stored in the boost::bind() result makes the referenced 
object effectively immortal.

To my surprise, I find that it's not destroyed even when I explicitly 
disconnect the resulting connection.

3. visitor discovers a weak_ptr to something other than a Trackable 
subclass:

Though I had to specialize boost::get_pointer() for weak_ptr myself, 
with that in place, this case works now. My problem is that I can't 
imagine every coder consistently remembering to convert a shared_ptr to 
weak_ptr before passing it to boost::bind().

4. visitor discovers a shared_ptr to a Trackable subclass:

This is the case you mention above. To tell you the truth, though, this 
doesn't look like an error to me. In effect, I have a choice between two 
different connection-management mechanisms.

Given that slot_type::track() is safer than my Trackable mechanism, I'd 
prefer to use that -- but unless we can somehow create a new boost::bind 
object that omits the bound shared_ptr, it's moot.

5. visitor discovers a weak_ptr to a Trackable subclass:

I currently use the slot_type::track() mechanism for this case too. In 
other words, once the visitor discovers a shared_ptr or weak_ptr, it 
stops caring about the pointee type.