Boost.Signals2 - tracking an object managed with tr1::shared_ptr - Boost-users

newer
[spirit] benchmarks/qi benchmarks...

Boost.Signals2 - tracking an object managed with tr1::shared_ptr

Monteleone, Nathan

10 Sep 2009 10 Sep '09

11:06 p.m.

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 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

Attachments:

attachment.html (text/html — 2.7 KB)

Show replies by date

Frank Mori Hess

11 Sep 11 Sep

4:31 p.m.

-----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 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-----

Frank Mori Hess

4:34 p.m.

-----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-----

Monteleone, Nathan

14 Sep 14 Sep

3:54 p.m.

New subject: Boost.Signals2 - tracking an object managed with tr1::shared_ptr

...

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

Frank Mori Hess

7:15 p.m.

New subject: [Boost-users] Boost.Signals2 - tracking an object managed with tr1::shared_ptr

-----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-----

Monteleone, Nathan

4:09 p.m.

New subject: Boost.Signals2 - tracking an object managed with tr1::shared_ptr

...

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 :)

5554

Age (days ago)

5558

Last active (days ago)

List overview

Download

5 comments

2 participants

participants (2)

Frank Mori Hess
Monteleone, Nathan