Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-08 21:23:03

On Thursday 08 August 2002 04:18 am, Brunen, Johannes wrote:
> This works pretty fine. However, when I tried to use a slot functor defined
> in class A it doesn't compile anymore:
[snip example]
> It produces the following error on MS VC++ 6.5:
> ..\..\..\..\Comp\Boost\boost/signals/slot.hpp(97): error C2664:
> 'boost::reference_wrapper<A::SlotFunctor const>
> boost::signals::detail::slot_base::get_invocable_slot(const A::SlotFunctor
> &,boost::signals::detail::signal_tag)': cann
> ot convert parameter 2 from 'boost::signals::detail::value_tag' to
> 'boost::signals::detail::signal_tag'
> No constructor could take the source type, or constructor overload
> resolution was ambiguous

Sorry for the delay. I'm not quite sure if it's a compiler bug or a bug in
Signals, but I'll track it down and get back to you.

> Would you be so kind to clarify the usage of slot_type, slot_function_type
> and of the automatic connection
> lifetime management a little bit for me? I would like to properly use the
> signals library.


slot_type is the type that holds a function object that can be the target of a
signal. Any time you create a function object for the signal to call, such as
boost::bind(&A::f, this, _1), it is turned into a slot_type instance. If you
every need to pass slots around temporarily before connecting them, use

slot_function_type is the actual callback type that is used internally in the
signal. This is the type that does the work of translating a call to the
signal to a call to the actual callback target. If you look at the code/docs,
you'll see that the default type is a boost::function object - that's where
the flexibility regarding what you can connect as a slot comes from. You can
actually override the slot_function_type, if you want to use a different type
of callback class. At least one user has done this to make slot calls

The automatic connection lifetime management lets you connect it, and forget
it. Any objects that derive from boost::signals::trackable will know about
connections they are involved in, and will disconnect those connections if
they are destroyed. For instance:

  A* a = new A;
  some_signal.connect(bind(&A::f, a, _1)); // #1
  // ...
  delete a;

This code will invoke undefined behavior normally, because there is a pointer
to 'a' in one of the slots connected to some_signal, so when we call
some_signal that slot will try to use the deleted pointer 'a'. However, if
class A derives from boost::signals::trackable, the connection made at #1
will be disconnected when A is deleted.


Boost list run by bdawes at, gregod at, cpdaniel at, john at