Boost.Signals2 - tracking an object managed with tr1::shared_ptr
Is it possible to use slot::track with a tr1::shared_ptr instead of a boost::shared_ptr? For example: std::tr1::shared_ptr<MyObject> o; typedef boost::signals2::signal<void(void)> SigType; SigType s; // Error: can't convert std::tr1::shared_ptr<MyObject> to boost::weak_ptr... s.connect(SigType::slot_type(&MyObject::function, o.get()).track(o)); According to the docs you HAVE to use boost::shared_ptr. I'm just hoping there's some traits specialization or something I can provide so that I can get away with using the tr1 version instead (all our code is already written with tr1). Thanks! -Nathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 10 September 2009, Monteleone, Nathan wrote:
Is it possible to use slot::track with a tr1::shared_ptr instead of a boost::shared_ptr?
Sorry, not at present. I've thought about it a bit, especially with respect to std::shared_ptr, but haven't gotten around to doing anything about it. It wouldn't be too hard to support some fixed set of shared_ptr types using boost::variant. Maybe an additional slow path that uses heap allocation and some type traits could support unforeseen shared_ptr types.
For example:
std::tr1::shared_ptr<MyObject> o; typedef boost::signals2::signal<void(void)> SigType; SigType s;
// Error: can’t convert std::tr1::shared_ptr<MyObject> to boost::weak_ptr… s.connect(SigType::slot_type(&MyObject::function, o.get()).track(o));
According to the docs you HAVE to use boost::shared_ptr. I’m just hoping there’s some traits specialization or something I can provide so that I can get away with using the tr1 version instead (all our code is already written with tr1). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqqe2cACgkQ5vihyNWuA4Ux8QCgkBLWJPceO9MhKWqHMlp3GeWA MusAoOChRRFcOaIz/WuJY6mN644bVB5p =uH2d -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 11 September 2009, Frank Mori Hess wrote:
On Thursday 10 September 2009, Monteleone, Nathan wrote:
Is it possible to use slot::track with a tr1::shared_ptr instead of a boost::shared_ptr?
Sorry, not at present. I've thought about it a bit, especially with respect to std::shared_ptr, but haven't gotten around to doing anything about it. It wouldn't be too hard to support some fixed set of shared_ptr types using boost::variant. Maybe an additional slow path that uses heap allocation and some type traits could support unforeseen shared_ptr types.
Oh, and the other solution would be to add yet more template parameters to the signal class (like the SlotFunction = boost::function) to permit the shared_ptr/weak_ptr types to be specified per-signal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqqfCIACgkQ5vihyNWuA4VimACfXwscUerSBqRH7ryW9HKB78Qn o5IAoMZ7MlW5HOEoYvpWJZ0glrFVgAMK =eH1R -----END PGP SIGNATURE-----
On Friday 11 September 2009, Frank Mori Hess wrote:
On Thursday 10 September 2009, Monteleone, Nathan wrote:
Is it possible to use slot::track with a tr1::shared_ptr instead of a boost::shared_ptr?
Sorry, not at present. I've thought about it a bit, especially with respect to std::shared_ptr, but haven't gotten around to doing anything about it. It wouldn't be too hard to support some fixed set of shared_ptr types using boost::variant. Maybe an additional slow path that uses heap allocation and some type traits could support unforeseen shared_ptr types.
Oh, and the other solution would be to add yet more template parameters to the signal class (like the SlotFunction = boost::function) to permit the shared_ptr/weak_ptr types to be specified per-signal.
Frank, First of all, thanks for your work on the signals2 library. Ideally I'd like to be able to provide extensions to support more than just the boost/tr1 smart pointer types. OpenThreads/OSG's ref_ptr would be one example. A template parameter couldn't give me that power unless it was a policy, right? For that reason I like your traits idea better. I sympathize with your reluctance to add "yet more" template parameters :) Any idea how other libraries dealing with the whole boost vs. std::tr1 namespace issue? Seems unfortunate to have to add template parameters all over the place for that, but I don't see any other way. Am I making a mistake by using tr1 for the stuff that is in tr1 and boost for everything else? This is also interesting, although it doesn't help with the tr1 namespace woes: http://boost.org/libs/smart_ptr/sp_techniques.html#weak_without_shared The gist of it is that you can make any object support weak_ptr with an internal shared_ptr to itself, with a null_deleter. Might be of interest for people wanting to track a wider variety of objects. -Nathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 14 September 2009, Monteleone, Nathan wrote:
This is also interesting, although it doesn't help with the tr1 namespace woes: http://boost.org/libs/smart_ptr/sp_techniques.html#weak_without_shared The gist of it is that you can make any object support weak_ptr with an internal shared_ptr to itself, with a null_deleter. Might be of interest for people wanting to track a wider variety of objects.
That's what signals2::trackable does. It's not a thread-safe scheme though, since the contained shared_ptr doesn't really own the object. One thing you could do is bind a weak_ptr as the "this" argument of the member function you are using as a slot, and define a get_pointer() function for your weak_ptr that throws an expired_slot exception when the weak_ptr expires, or returns a shared_ptr otherwise. That would work almost the same as the track(), except the slot could only be removed from the slot list by signal invocations and not during connect() calls. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqullIACgkQ5vihyNWuA4VRgQCfYrvi3me6M9rqr4A5OnivsuNu i8sAoMmOnUOWizwzHsH1qOPMkpJlqnP9 =WFCO -----END PGP SIGNATURE-----
For that reason I like your traits idea better. I sympathize with your reluctance to add "yet more" template parameters :)
Shoot, I confused myself. Using traits is still going to require more template parameters. I still like the traits approach though :)
participants (2)
-
Frank Mori Hess -
Monteleone, Nathan