[signals] connection::add_tracked() proposal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to propose we add an add_tracked() function to the connection object. This would allow an arbitrary shared_ptr/weak_ptr to be added to the list of objects tracked for the slot. The justification is to allow for situations where an object needed by the slot is not directly owned by a shared_ptr, or doesn't directly correspond to an argument of the bound function. For example, the bound argument might be contained inside another object which is in turn managed by a shared_ptr. We could actually dump boost::track() entirely if we wanted, if we have add_tracked(). - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF3Gxq5vihyNWuA4URAmS+AJkB3tgE/8p7GlCY+xq+UwfTFjZwigCgoQh0 fgQdVgH73Oh3j1g34HNy+JY= =3UVL -----END PGP SIGNATURE-----
On 2/21/07, Frank Mori Hess
So, for example, foo is what we want to track, but bar (somehow inside of foo) is what we want to bind/call? Shouldn't that all happen on the same function call: signal.connect(bind(bar, func), foo) // pass foo in as the object that guarantees bar's lifetime. So a 'guarantor' parameter. Is that what you mean? If so, I'd like that to be part of the conenct as opposed to a separate function. Tony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2007 13:04 pm, Gottlob Frege wrote:
Yes, I suggested a member function on the connection because that allows you to add an arbitrary number of tracked objects to a connection. If they are passed as parameters to connect, you are either limited to tracking a single object (or fixed number with default parameters), have to pass the objects in a container, or have to make connect a variadic function. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF3JG+5vihyNWuA4URAq+/AJwOEkM/jwOM80Jb0uqRPpcrSp6lEACfSHhi t9FAwmDoIW4OCH0klInCviU= =iErz -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2007 14:08 pm, Gottlob Frege wrote:
Well, we could just keep around boost::track() if connection::add_tracked() is considered too ugly for the common case. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF3KXG5vihyNWuA4URAvn9AJ4mDcNtfbyA1APEfP/NEku+zupXNwCfUKCl rZR+mxuYY5gXQfi2tZSHeK8= =q7St -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2007 15:04 pm, you wrote:
Oh, another idea is to put add_tracked() in the slot class instead of the connection class. Then all the tracked objects could be added to the slot before the connection is made, which would be slightly less error prone wrt races. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF3KfO5vihyNWuA4URAjU4AJ9Y29IN+8je6MUtQ9EvcUEQyckdyACePo3V ONZXl4UY7E9NkZfnO0r5D68= =ZRX3 -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
A user can already have loosely related pointers tracked by using a specialized function object and overloading visit_each. Giving too many alternative ways to achieve the same goal may confuse more than it helps. I personally find a small comprehensible interface more useful in most cases and like to find solutions based on my knowledge of the language and not the set of available library functions. Regards Timmo Stange
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2007 16:45 pm, Timmo Stange wrote:
I disagree. By that logic, providing boost::bind is a mistake, because the user could just as well create a specialized function object in order to connect a slot which doesn't exactly match the signal's signature. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF3MCo5vihyNWuA4URArc3AKCU8TblOHPO95AYwGcWKISjohpRLgCgtyB9 pq6cT5WIoqPrvkvt6csKBVI= =EGrT -----END PGP SIGNATURE-----
participants (4)
-
Frank Mori Hess -
Frank Mori Hess -
Gottlob Frege -
Timmo Stange