[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
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
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:
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
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-----
On 2/21/07, Frank Mori Hess
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
Do you think having a slot that requires multiple objects to be tracked is common? Should we have both the single param guarantor (typical case?) plus the ability to add additional things to track? Tony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 February 2007 14:08 pm, Gottlob Frege wrote:
Do you think having a slot that requires multiple objects to be tracked is common? Should we have both the single param guarantor (typical case?) plus the ability to add additional things to track?
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:
On Wednesday 21 February 2007 14:08 pm, Gottlob Frege wrote:
Do you think having a slot that requires multiple objects to be tracked is common? Should we have both the single param guarantor (typical case?) plus the ability to add additional things to track?
Well, we could just keep around boost::track() if connection::add_tracked() is considered too ugly for the common case.
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:
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().
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:
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 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-----
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 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.
Hm, ok, I see boost::bind a little differently, but as you mention it, I would prefer such an approach above a member function (a tracked object binder). Regards Timmo Stange
On Wednesday 21 February 2007 05:12 pm, Timmo Stange wrote:
Hm, ok, I see boost::bind a little differently, but as you mention it, I would prefer such an approach above a member function (a tracked object binder).
How about a two-argument form of boost::track()? One argument would be the value passed through to bind (or directly to the connect call), the other argument would be the shared_ptr used for tracking. -- Frank
participants (4)
-
Frank Mori Hess -
Frank Mori Hess -
Gottlob Frege -
Timmo Stange