Re: [Boost-users] [signals] Automatic connection management and MT

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-05 18:28:42

Frank Mori Hess wrote:

[...]
> Are there any possible
> work-arounds besides using a private constructor with a static factory 
> function (a solution which doesn't extend well to derived classes), or 
> doing the connection setup in a member function that has to be called 
> separately after the object is constructed?
> 
> Is there some way to have signals::tracked initially hold a full 
> shared_ptr, until it is known that the object has had a chance to have its 
> ownership passed to an external shared_ptr?  Or maybe a version of 
> shared_from_this() which returns a shared_ptr whose use_count is initially 
> artificially inflated by one, until an external shared_ptr comes along and 
> tries to increment the use count.

I understand your dilemma, but this can't be solved unless we decide to
use something completely different from shared_ptr. The idea is that
by connecting a slot to a signal, the lifetime tracking of bound
objects is started and as soon as all shared_ptr references go out of 
scope, the slot is disconnected. Even if we could open up a loophole,
you could never start tracking from the constructor itself, as the
external shared_ptr reference to your object is only initialized when
the constructor returns. You would need a second call to the member
function to start tracking, in which case you can just as well set
up the connection there.
But is that really a problem? If you set up the connection from the
constructor, you can also disconnect it in the destructor and don't
need automated tracking.

On a side note: I don't think my current "tracked" wrapper will allow
binding to a pointer to member function. It doesn't have overloads
for dereferencing and the implicit conversion to shared_ptr won't
help here.

Regards

Timmo Stange