Boost logo

Boost Users :

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?


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net