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

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 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 and shared_ptr -- or weak_ptr and weak_ptr. 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?