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