Re: [boost] [smart_ptr] trunk versionof enable_shared_from_thisincompatible with TR1

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-29 15:18:02

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 03 May 2008 13:52 pm, Peter Dimov wrote:
> Frank Mori Hess:
> > What I'm thinking is more along the lines of how a weak_ptr goes from
> > "expired" to "good".  Currently, that can only happen by assignment of a
> > new shared_ptr.  And assignment of one expired weak_ptr has no effect on
> > any copies of the weak_ptr, they stay expired.
>
> This is correct as far as it goes. But in the case I showed, no assignment
> happens to any of the weak_ptr instances. Consider how weak_ptrs go from
> use_count of 1 to use_count of 0 without any assignment. This is the same
> event in reverse. It can't normally occur now, of course.
>
> Remember that use_count() does not report the state of a particular
> instance, it reports program-wide state (the number of shared_ptr instances
> sharing ownership with *this). It can and will go up and down without any
> changes to *this.
>
> > Yes, but in the case of a long-lived signal with many short-lived
> > connections, it would effectively create a resource leak when relying on
> > automatic connection management.
>
> Well, there would be no automatic connection management, so obviously
> relying on it would be a bad idea. :-) One would have to use scoped
> connections or manual disconnects in the destructor, as usual.

To respond to a month-old post (sorry): disconnecting in the destructor is not 
thread-safe, since the slot may still be running concurrently when 
disconnect() returns.  Automatic connection management has to be used, so the 
signal can lock its weak_ptr and prevent the tracked object from destructing 
while the slot is still being run.  I still like the idea of something like

template<typename T>
future<weak_ptr<T> > future_weak_from_this(T *this)

which would be safely useable in the constructor, and allow distinguishing "no 
owner yet" from "expired".  It doesn't belong in the smart_ptr lib due to the 
dependency on a future lib, but maybe it could be slipped into boost 
somewhere when futures are added.

By the way, did you ever decide if you wanted to add a raw pointer argument to 
sp_accept_owner() due to the dynamic_cast issue?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPwFq5vihyNWuA4URAiVaAKDY6OdVuVwUCCKvkf63EtJicRGj7wCg5kl5
ygKvKIKG2lpfg8Y5VH3Fxo4=
=dZfa
-----END PGP SIGNATURE-----