txmpp

http://silas.sewell.org/blog/2010/06/16/txmpp-a-bsd-licensed-cpp-xmpp-library/

libjingle

 

• Signals

libjingle uses the to facilitate communication between objects. sigslot is a generic framework that enables you to connect a calling member to a receiving function in any class (including the same class) very simply. The way it works is this:

1. The sending class declares a member variable, called a signal, using a special template-like syntax. This signal defines the parameters of the listening function.
2. The listening class implements a function with the same number, type, and sequence of parameters as the signal. This is sometimes called the receiver or the slot. (Note: this can even be the same class as the one that declared the signal.) This function cannot return a value (e.g., returns void). The receiver must inherit sigslot::has_slots<>.
3. The listener connects to the signal by calling the signal's connect method, passing in a pointer to the instance of the listening object, and the address of the implementing class function.
4. The sender calls its signal member as if it were a function, passing in the appropriate parameter types as declared. It can pass parameters by either value or reference.

You can connect as many signals as you like to a common slot. libjingle sometimes assigns multiple signals to a single slot in order to consolidate its message handling. Conversely, several objects declare a signal object in order to broadcast commonly needed messages from a single point (for example, alerts sent when a connection state changes). sigslot takes care of disconnecting callbacks and dereferencing when objects are destroyed.

The following code demonstrates using sigslot:

1 // Class that sends the notification. 2 class Sender  { 3  4   // The signal declaration.  5   // The '2' in the name indicates the number of parameters. Parameter types  6   // are declared in the template parameter list. 7   sigslot::signal2
     
       SignalDanger; 8  9   // When anyone calls Panic(), we will send the SignalDanger signal.10   void Panic(){11     SignalDanger("Help!", std::time(0)); 12   }13  14  // Listening class. It must inherit sigslot.15 class Receiver : public sigslot::has_slots<>{16 17   // Receiver registers to get SignalDanger signals.18   // When SignalDanger is sent, it is caught by OnDanger().19   // Second parameter gives address of the listener function class definition.20   // First parameter points to instance of this class to receive notifications.21   Receiver(Sender sender){ 22         sender->SignalDanger.connect(this, &Receiver.OnDanger);23   }24 25   // When anyone calls Panic(), Receiver::OnDanger gets the message.26   // Notice that the number and type of parameters match27   // those in Sender::SignalDanger, and that it doesn't return a value.28   void OnDanger(string message, std::time_t time){29     if(message == "Help!")30     { 31       // Call the police32       ...33     }34   }35 ...36 }
     

Many classes in the code send signals to notify listeners of important events. For example, Call::SignalSessionState sends notifications when you send or receive a connection attempt. Your application must connect to these signals and act appropriately.

The general convention in libjingle code is to prefix the name of a signal with Signal: e.g., SignalStateChange, SignalSessionState, SignalSessionCreate. Listener methods intended to connect to signals are typically prefixed with On, e.g., OnPortDestroyed(), OnOutgoingMessage(), OnSendPacket().

See the for more details.