Re: [Boost-users] Beginner question: Why boost::signal creates another instance of the slot object ?

On Fri, Aug 20, 2010 at 1:25 PM, Mauricio Gomes wrote:

Hi,

I am still digesting the information. I understand the problem with lifetime management but when I do:

sig.connect(x);

and x being the listener, I would expect x to be called, not another instance of X. I will study more what you guys have explained. I hope at some point it will click on my mind. :)

Think of it this way, what connect accepts is a callable, not an instance of an object or anything like that. A callable *will* be copied, potentially many times. Your object instance fulfills the needed parts of callable, but its logic is improperly defined as it does not handle 'many' copies, hence it fails at the overall concept. Need to wrap it in another callable that does implement the callable concept properly, such as boost::ref or boost::bind or whatever other dozen things or custom things. Remember this, you are not connecting an object/instance, you are connecting an action, most tutorials/examples/etc... show off an action using boost::bind, which is fully callable, to an action of an object/instance. On Fri, Aug 20, 2010 at 1:25 PM, Mauricio Gomes wrote:

...

As for your initial problem of the receiver being dis-associated from the callable, it's probably because it's not properly copyable I thought the compiler would generate a copy constructor and assignment operator suitable for S. Is not the case ?

struct S {   int x;

  S (): x(0) {}

  void operator () (int i)   {       std::cout << "&slot1 = " << this << std::endl;       x = i;       std::cout << "slot1.x = " << this->x << std::endl;   } };

Thank you !

2010/8/20 Lars Viklund :

...

AMDG

As for your initial problem of the receiver being dis-associated from the callable, it's probably because it's not properly copyable.

It's normally good form to make things that should not be copied boost::noncopyable or otherwise artificially restricted from copying, in order to catch such assumptions at an early stage instead of through runtime bugs.

-- Lars Viklund | zao@acc.umu.se _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Mau _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users