[boost-users][bind, signal] binding a weak_ptr?
Hello, When using shared_ptr, we usually take an advantage of weak_ptr to break the "cycles". But sometimes the "forth connection" between the objects is by means of shared_ptr, while the "back connection" is by means of signal-slot connection. Like this: shared_ptr<Class1> o1; shared_ptr<Class2> o2; o1->someSignal_->connect(bind(&Class2::responder, o2)); // besides, o2 has a shared_ptr to o1 I'd like this signal-slot to be "weak", i.e. instead of "bind(&Class2::responder, o2)" I wish it could be "bind(&Class2::responder, weak_ptr(o2))" - which is illegal. Of course, I can define (and connect to the signal) a wrapping functor that would store a weak_ptr to the wrapped object, and would try to lock it in operator(). But probably boost already have some off-the-shelf solution for this issue? Thanks!
Oh, I see that thread_safe_signals already does what I need - one can safely bind a regular pointer instead of shared_ptr (by the way, is it safe to do this if the object already inherits from enable_shared_from_this?). Is it planned to be released as a part of 1.36?
o1->someSignal_->connect(bind(&Class2::responder, o2)); // besides, o2 has a shared_ptr to o1
I'd like this signal-slot to be "weak", i.e. instead of "bind(&Class2::responder, o2)" I wish it could be "bind(&Class2::responder, weak_ptr(o2))" - which is illegal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 22 July 2008 10:37 am, Igor R wrote:
Oh, I see that thread_safe_signals already does what I need - one can safely bind a regular pointer instead of shared_ptr (by the way, is it safe to do this if the object already inherits from enable_shared_from_this?).
Yes, you just need to pass a shared_ptr (or weak_ptr) to the slot's track() function which owns the object (either directly or indirectly).
Is it planned to be released as a part of 1.36?
No, it's sitting in the review queue until someone volunteers to be review manager, although Doug Gregor suggested it should only need a mini-review. There will at least need to be some namespace/header location rearrangement. Plus the postconstructor stuff might get dropped depending on sp_accept_owner getting into a boost release of shared_ptr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIhgFm5vihyNWuA4URAhAcAKCLksBuYQpjkDpsF16pe+850ThJUQCeP6HG vXYJLORLXDAD3OKZolNw3uM= =YQH3 -----END PGP SIGNATURE-----
On Tuesday 22 July 2008 11:48:54 am Frank Mori Hess wrote:
Oh, I see that thread_safe_signals already does what I need
[snip]
Is it planned to be released as a part of 1.36?
No, it's sitting in the review queue until someone volunteers to be review manager, although Doug Gregor suggested it should only need a mini-review.
I volunteer to write a review for this pretty much as soon as it gets a review. I am already using it in (lightly tested) production code. Who do we need to beg to get a review manager? Ravi
...by the way, in the document of the thread_safe_signals the
following example appears:
// ...
boost::shared_ptr<NewsMessageArea> newsMessageArea(new
NewsMessageArea(/* ... */));
// ...
deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews,
newsMessageArea, _1).track(newsMessageArea));
I.e., the slot is both tracked *and* bound as shared_ptr.
But if it's bound as a shared_ptr, it will never expire, so the
tracking is useless here, isn't it? Or am I miss something?
Thanks,
Igor'.
2008/7/22, Igor R
Oh, I see that thread_safe_signals already does what I need - one can safely bind a regular pointer instead of shared_ptr (by the way, is it safe to do this if the object already inherits from enable_shared_from_this?). Is it planned to be released as a part of 1.36?
o1->someSignal_->connect(bind(&Class2::responder, o2)); // besides, o2 has a shared_ptr to o1
I'd like this signal-slot to be "weak", i.e. instead of "bind(&Class2::responder, o2)" I wish it could be "bind(&Class2::responder, weak_ptr(o2))" - which is illegal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 22 July 2008 11:57 am, Igor R wrote:
...by the way, in the document of the thread_safe_signals the following example appears:
// ... boost::shared_ptr<NewsMessageArea> newsMessageArea(new NewsMessageArea(/* ... */)); // ... deliverNews.connect(signal_type::slot_type(&NewsMessageArea::displayNews, newsMessageArea, _1).track(newsMessageArea));
I.e., the slot is both tracked *and* bound as shared_ptr. But if it's bound as a shared_ptr, it will never expire, so the tracking is useless here, isn't it? Or am I miss something?
Yes, you're right, thanks for reporting that. I've added a .get() so it binds a raw pointer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIhiIe5vihyNWuA4URAvHNAKC2rk+WWJNFGsj/+GWw868HNeXDfwCeMbue gz4qD5xekSL1pp+W2esIDE0= =NSev -----END PGP SIGNATURE-----
participants (3)
-
Frank Mori Hess -
Igor R -
Ravi