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-19 11:55:36

Frank Mori Hess wrote:

> On Wednesday 18 February 2009, Nat Goodspeed wrote:

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

> Yes, that's why I suggested you could have the visitor give a compile error on 
> finding a shared_ptr<shared_trackable> in the bind functor.

I see. In fact, that compile error could be what prompts our coders to 
convert to weak_ptr when passing a shared_ptr to boost::bind().

Then there's the interesting question as to whether my visitor should 
complain about *any* shared_ptr in the boost::bind() object, since any 
such object becomes effectively immortal.

If my visitor handles weak_ptr<anything> by passing the corresponding 
shared_ptr<anything> to slot_type::track(), then it seems reasonable to 
me to force our coders to convert any shared_ptr to weak_ptr before 
boost::bind()ing it. Does that make sense?

In that case I don't really understand why my visitor would need to 
distinguish between shared_ptr<shared_trackable> and 
shared_ptr<anything_else> -- or weak_ptr<shared_trackable> and 
weak_ptr<anything_else>.

Put differently, shared_trackable only seems to me to make a difference 
when the visitor encounters a plain pointer or reference to it. In that 
case, the visitor can use shared_trackable::shared_from_this() and still 
pass a shared_ptr to slot_type::track(). Am I overlooking something?