-----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-----