Boost logo

Boost Users :

Subject: Re: [Boost-users] [signals2] scoped_connection strangeness
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2010-06-25 11:37:36


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

On Friday 25 June 2010, Igor R wrote:
> > There isn't a way right now.  It would require adding a method to signals
> > to do a cleanup, plus a method to wait for any concurrent invocations to
> > complete.
>
> Why to wait?

You wouldn't have to. I'm just assuming people who find it unacceptable to
let the signal decide when it needs to destroy the slot object have some
reason to need to know that the object has really been destroyed, and not
just know that it will probably be destroyed sometime soon.

> All I want here is that after I call my_slot::disconnect, the my_slot
> instance (being managed by means of some smart ptr) will die sooner or
> later.

It will already die sooner or later, without doing any forced cleanup,
assuming the signal is periodically connected to, or invoked, or eventually
destroyed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkwkzUEACgkQ5vihyNWuA4UT5QCggusaKzm54lI4Fh6OgIpCBptB
LAkAoNZGdZH9fSv8cKALRi+9VJBs4XU5
=Nj+n
-----END PGP SIGNATURE-----


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net