-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 01 February 2007 18:37 pm, Timmo Stange wrote:
1. Cleanup only takes place when the signal is actually called, so it may end up tracking a large amount of pointers in a situation where the connection and observer destruction frequency is much higher than the signal call rate. I'm using it to notify thread local storage owners of threads exiting, for example. You can imagine that this won't work well for a signal that is very likely to be called only once at application shutdown, while an arbitrary amount of slots can be connected and disconnected in the meantime. If I'm not mistaken, your current implementation has the same problem for manual disconnections.
Good point. I'll add another boost::function callback to the connection body that it will call on disconnect, passing a shared pointer to itself as the argument. The callback will run code in the signal to find the pointer in its connection list and erase it, and the connection body would destruct when it returns from disconnect().
2. Using an overload only allows tracking of a fixed number of objects. You're currently just considering the situation in which the object to which the member function is bound to can be tracked, but as far as I understand it, signals::trackable allows you to monitor every bound argument, including ordinary call parameters.
I hadn't considered that. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFw03b5vihyNWuA4URAjDeAJ9fEdCnmWRbL0KHvSzZ8CAYzk7PUwCgv1fJ IQqCH5UMjAl8qGMv44elQkU= =Obc2 -----END PGP SIGNATURE-----