Using boost.signals with boost.bind
Hi,
I have one problem with boost.bind and boost.signals I can't understand.
Source code is the best description, therefore
#include <iostream>
#include
Sergey Kishchenko wrote:
I have one problem with boost.bind and boost.signals I can't understand.
I have used bind with signals in a simpler way than you have in this
example. It works well for me. I don't know if you are doing it in a
more complex way for a reason, but hopefully my simple version will be
some help.
class MyClass
{
public:
MyClass(void)
{ // define the connection using bind
mySignal.connect(
boost::bind(&MyClass::MySlot,this,_1));
}
boost::signal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 13 October 2008 08:25 am, Sergey Kishchenko wrote:
boost::shared_ptr
apSig(new signal_type()); apSig->connect(binded_func); (*apSig)(); apSig.reset(new signal_type()); boost::signals::connection con = apSig->connect(binded_func); std::cout<<"Connected: "<
Program output:
Func::operator(42) Connected: 0 Blocked: 1
Ie, if i create new signal and then try to connect to the same slot, it fails. If I use not boost::bind object but only boost::function as slot, all works ok. I can not understand, why? I used Boost 1.34.1, gcc 4.1.2
It looks like a bug to me. In boost.signals, the slot has a shared_ptr to its signal/slot connection, which I think it uses for automatic connection management. So it looks like it was coded under the assumption a slot object (or any of its copies) would not be re-used with more than 1 signal. The slot is probably (permanently) auto-disconnecting when the first signal it was connected to is destroyed. The signals2 lib, which might get reviewed soon if there are enough reviewers, doesn't show this problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI9KCX5vihyNWuA4URAi7uAJ9rwpPp00P/bs03ayUHPIjW3mvtfwCgvCwn 7RqIthZ9NIY6Dc39r7fOJJk= =UTWd -----END PGP SIGNATURE-----
It works. Thank you!
Signals2 lib is brilliant. I'll use it in my app. I hope this lib will be
part of the next Boost release.
With regards,
Sergey Kishchenko
2008/10/14 Frank Mori Hess
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 13 October 2008 08:25 am, Sergey Kishchenko wrote:
boost::shared_ptr
apSig(new signal_type()); apSig->connect(binded_func); (*apSig)(); apSig.reset(new signal_type()); boost::signals::connection con = apSig->connect(binded_func); std::cout<<"Connected: "<
Program output:
Func::operator(42) Connected: 0 Blocked: 1
Ie, if i create new signal and then try to connect to the same slot, it fails. If I use not boost::bind object but only boost::function as slot, all works ok. I can not understand, why? I used Boost 1.34.1, gcc 4.1.2
It looks like a bug to me. In boost.signals, the slot has a shared_ptr to its signal/slot connection, which I think it uses for automatic connection management. So it looks like it was coded under the assumption a slot object (or any of its copies) would not be re-used with more than 1 signal. The slot is probably (permanently) auto-disconnecting when the first signal it was connected to is destroyed. The signals2 lib, which might get reviewed soon if there are enough reviewers, doesn't show this problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFI9KCX5vihyNWuA4URAi7uAJ9rwpPp00P/bs03ayUHPIjW3mvtfwCgvCwn 7RqIthZ9NIY6Dc39r7fOJJk= =UTWd -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Sergey,
On Tue, Oct 14, 2008 at 7:27 AM, Sergey Kishchenko
It works. Thank you! Signals2 lib is brilliant. I'll use it in my app. I hope this lib will be part of the next Boost release.
You could greatly contribute towards a possible acceptance of Signals2 by signing up to be a reviewer. You can read the original call for reviewers here: http://tinyurl.com/3jkxrg [nabble] As you have moved from using Boost.Signals to Signals2, I think your experience in transitioning would be very valuable to share during the review. Please let me know if you are interested. Kind regards, Stjepan
Hi, I had a similar problem with boost signal in version 1.36.0. I am now using Boost.Signals2 to see if fixes the issue. As it is a header only lib I copied it to existing boost 1.36.0 folder. I get the following error in VS2005 error C3861: 'TryEnterCriticalSection': identifier not found C:\Software\Boost\boost_1_36_0\boost_1_36_0\boost\signals2\detail\lwm_win32_cs.hpp 86 Are there additional libs / headers I need to add? Thanks Stjepan Rajko wrote:
Hi Sergey,
On Tue, Oct 14, 2008 at 7:27 AM, Sergey Kishchenko
wrote: It works. Thank you! Signals2 lib is brilliant. I'll use it in my app. I hope this lib will be part of the next Boost release.
You could greatly contribute towards a possible acceptance of Signals2 by signing up to be a reviewer. You can read the original call for reviewers here: http://tinyurl.com/3jkxrg [nabble]
As you have moved from using Boost.Signals to Signals2, I think your experience in transitioning would be very valuable to share during the review. Please let me know if you are interested.
Kind regards,
Stjepan _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- View this message in context: http://www.nabble.com/Using-boost.signals-with-boost.bind-tp19954096p2003626... Sent from the Boost - Users mailing list archive at Nabble.com.
On Friday 17 October 2008 12:06, asio_user wrote:
I had a similar problem with boost signal in version 1.36.0. I am now using Boost.Signals2 to see if fixes the issue.
As it is a header only lib I copied it to existing boost 1.36.0 folder. I get the following error in VS2005
error C3861: 'TryEnterCriticalSection': identifier not found C:\Software\Boost\boost_1_36_0\boost_1_36_0\boost\signals2\detail\lwm_wi n32_cs.hpp 86
Are there additional libs / headers I need to add?
It seems TryEnterCriticalSection only exists if you are compiling for windows NT 4 and later. Probably the easiest thing for you to do is just delete the entire try_lock() method that uses TryEnterCriticalSection. I only added it so signals2::mutex would fully implement the Lockable concept from Boost.Thread. Signals2 doesn't actually use try_lock().
participants (6)
-
asio_user
-
Frank Mori Hess
-
Frank Mori Hess
-
Jeff Gray
-
Sergey Kishchenko
-
Stjepan Rajko