Signals and Delegates

Type-safe callback mechanism for connecting signals to slots and delegates. More...

Classes
class	Callable< R, As >
	An interface for all callable entities. More...
class	Connectable
	Connection Management for Signal and Slot Objects. More...
class	Connection
	Represents a connection between a Signal/Delegate and a slot. More...
class	ConstMethod< R, ClassT, As >
	Adapter for const class methods. More...
class	ConstMethodSlot< R, ClassT, As >
	Wraps ConstMethod objects so that they can act as Slots. More...
class	Delegate< R, As >
	Delegates an action to a slot. More...
class	DelegateSlot< R, As >
	Wraps Delegate objects so that they can act as Slots. More...
class	Function< R, As >
	Wraps free functions into a generic callable for use with the signals/slots. More...
class	FunctionSlot< R, As >
	Wraps Function objects so that they can act as slots. More...
class	Invokable< As >
	Interface for invokable entities. More...
class	Lambda< L, R, A >
	Adapts a lambda or function object as a callable. More...
class	LambdaSlot< L, R, A >
	Adapts a Lambda for use as a slot. More...
class	Method< R, ClassT, As >
	Adapter for class methods. More...
class	MethodSlot< R, ClassT, As >
	Wraps Method objects so that they can act as Slots. More...
class	Signal< As >
	Multicast Signal to call multiple slots. More...
class	SignalSlot< As >
	Wraps Signal objects so that they can act as Slots. More...
class	Slot
	Endpoint of a signal/slot connection. More...
class	BasicSlot< R, As >
	Base type for various "slot" types. More...
class	BoundSlot< R, Tuple, Indices >
	Slot produced by binding a final argument to another slot. More...

Detailed Description

Callback mechanisms for event handling have become ubiqitous in todays application frameworks. Older examples are the use of function pointers as callbacks or the message maps found in the MFC toolkit. More modern approaches include the .NET delegates and so-called signal-slot techniques. When signals and slots are used, objects can communicate with each other by connecting a signal of one object to the slot of another object. In most cases connection management features are built-in so that an object closes all it connections automatically when it gets destroyed. Once the connection has been established, all connected slots are called when a signal is send. Connecting signals to slots is type-safe i.e. a signal can only be connected to a slot that matches the signal's signature. At the same time it allows a great deal of flexibility (loose coupling), since the caller has no intimite knowledge of the callee. A simple but real example might look like this:

int main()
{
    Pt::System::Application app;
 
    Pt::System::Timer timer;
    timer.setActive( app.loop() );
    timer.start(1000);
    timer.timeout() += Pt::slot(app, &Pt::System::Application::exit);
 
    return app.run();
}

This program will simply exit, when the timer expires after 1000 ms. The application object is the callee and the member function Application::exit serves as a slot. The timer is the caller, which has a signal called timeout.

Non-generic lambdas and function objects derive their slot signature from operator(). Generic lambdas use an explicitly stated slot signature. The callable must be copyable because a connection clones its slot. A lambda slot cannot be removed with operator-= because captured values do not have general equality. Retain the returned Connection and close it when no context is supplied.

  Pt::Signal<int> signal;
  Pt::Connection connection = signal +=
    Pt::slot([this](int) { add(42); });
 
  Pt::Delegate<int, int> delegate;
  delegate += Pt::slot<int, int>([](auto value) { return value + 1; });
  int result = delegate.call(41);
 
  connection.close();
 
  Pt::Connectable context;
signal += Pt::slot(context, [this](int) { add(42); });

Destroying the context closes its bound connections automatically. The context must outlive every unsafe capture while the connection remains open.