-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's occurred to me that thread-safe automatic connection management for signal/slot connections made in an object's constructor to one of its member functions could be accomplished by using a boost::trackable class that looks like class trackable: public enable_shared_from_this<trackable> { //... }; Above, I'm only requiring the "classic" enable_shared_from_this functionality, no special support for shared_from_this in constructors, etc. You would derive from trackable, visit_each would discover it inside bind objects, and its destructor would disconnect its associated connections, similar to how the current signals library works. It would do a bit more though. When the signal is invoked, it would: 1) check that the connection has not been disconnected. If not, it calls shared_from_this() to obtain a shared_ptr which can be used for connection tracking in the usual thread_safe_signals way. Calling shared_from_this can be made safe since the trackable destructor (which disconnects) will be called before the enable_shared_from_this destructor. 2) if the shared_ptr from shared_from_this is empty, that means the trackable object is either in the process of being destroyed, or hasn't been passed to an external shared_ptr owner yet. In either case, the slot is skipped by the signal invocation. However, there is a downside to this and other schemes where the signal/slot connection is made in the constructor but blocked until the object is passed to an external shared_ptr. In a common use case, an observer will connect to an observed object's signal and then manually query the observed object once to get its initial state. It can then rely on the signal to keep in sync with any changes the observed object undergoes. If the signal is blocked until the observer is owned by an external shared_ptr, it raises the possibility of the observer getting out of sync with the observed, since a signal could occur and be missed after the manual query of the observed object's initial state. So, doing all the connection setup in a postconstructor still seems preferable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIUS7c5vihyNWuA4URAhPIAKC40cK1kgX9o7aPYILBaHZu3jwZhQCfYFjw o/drv0EOsHqvEt+7exy/PDo= =Lj6m -----END PGP SIGNATURE-----