rarely talk about programming unless it comes to some new idea or something fun. However, in this article, I’m going to summarize a part of experiences in my career, about important concepts that I’ve learned and used: signals and slots. First appear and remain as fundamental concepts in the Qt library (“Qt” pronounced “cute” – which is so cute as a cross-platform application framework), the concepts has been adapted and developed into some other libraries (such as boost) and are being proposed as next standards for C++ language.

Please note that we’re talking C/C++ here, although signals & slots has been brought to many other languages (Java, Python, Ruby, JavaScript, etc.) Every coin has two sides and C/C++ is no exception, it has its own advantages and disadvantages (depend on types of applications). But the thing I like about C/C++ is that its half – civilized nature made it a strong language: the balance between abstraction and comprehensiveness has always been considered as core factor.

Noone want to build general applications using Assembly, and noone want to write lengthy code just for some simple features. To adhere the doctrine, strong – abstraction concepts must be introduced to capture grammar of the language, and simple, clear syntax that would make the code concise and comprehensive.

I came to signals & slots as solution to problems I’ve met when leading the CMS project, a DVRs managing software (client & server) with complicated GUI: a few screens, each screen can have a dozen tabs, each tabs can have hundreds of controls. Events on one control can affect other controls on other tab or screen, events can be user inputs as well as various signals come from dozens of (managed) network client machines.

The overwhelmingly – complicated communications surpass every MPM (message passing method), then signals & slots appeared as a saviour solution. To be simple, signals & slots is a very efficient mean of interaction between objects within a process space. I personally think it would be the next metaphor extension added to C/C++ language. Structure of this post would be as follow:

1. Introduction to signals & slots, from raw to abstract concepts.

2. ISO C++ compliant and cross – compiler, cross – flatform problems (would discuss about delegate and how function pointer has evolved from C to C++).

3. Different implementations of signals & slots: Qt, boost, sigslot, libsigc++…

1.   INTRODUCTION

Flow of code is no more than a series of function call, and to perform asynchronous function call, traditional C programming use callback. A callback is a pointer to a function, so if you want a processing function to notify you about some event, you pass a pointer to another function (the callback) to the processing function. Callbacks have two fundamental flaws: firstly, they are not type-safe, we can never be certain that the processing function will call the callback with the correct arguments. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call. In C, to define function pointer, you would write something like this:

When move to C++, things are a bit more complicated (note the weird syntax ->* to call a member function through pointer).

Though a very strong concept in C, function pointer add little to the language C++. The only two uses of member function pointer in C++ are:

• Demonstrate the tricky syntax of the language.

• Help in implementation of delegate.

Now, imagine slots as invisible communication channels, every object can register to listen to some channels by providing delegates (pointer to a member function). The delegate would be invoked when slot is “filled” with a signal. The signals and slots mechanism is type safe: signature of a signal must match signature of the receiving slot. Signals and slots are loosely coupled: a class which emits a signal neither knows nor cares which slots receive the signal. To summarize the benifits:

• Syntactically neater: signals & slots make for very readable code: you define the signals, you define the slots, then you wire them up.

• Inherently robust: when either end of a signal/slot connection is destroyed, the connection is automatically removed. It is therefore impossible to emit a signal and have it arrive at a class that has already been deleted. Best of all, you don’t need to write any cleanup code.

• Easier code reuse: since the thing that has to type-agree is the signal and the slot, not the whole class interface, it is much easier to plug together disparate classes that had never initially been intended to work in that way.

2.   DELEGATE

To summarize section 1: pointer is the root of all evils. Function pointer is the physical of callback method traditionally used in C programming. When evolved to C++, the C++ standard committee failed to address how to define function pointer to a single C++ object. With common-sense knowledge, we know that it take two elements to represent the thing: first is the address of the object itself (the implicit pointer this), second is pointer to the object’s member functions. The undefined land leads to different implementations across various compilers.

Contrary to common belief, the actual physical storage of pointer differs between various compilers, and even differs between types of pointer, e.g: pointer to a single – inheritance object, an multiple – inheritance one or virtual inheritance. The table below shows how many bytes it take to store pointers on different compilers (just make use of the operator sizeof). Then to calculate the actual member function’s address, each compiler uses one kind or another of offset:

So, delegate is just the new name for pointer to (an object’s) member function. The hard part really is that: since each compiler stores different type of pointers differently, there’s need for a way to store delegate in a universal manner: cross compilers and cross flatforms. Various techniques have been proposed by excellent programmers. Please refer to the articles below for specific techniques. I personally would prefer the method of Quynh Nguyen, an engineer at Global Cybersoft (Vietnam) Ltd.

• Don Clugston: Member Function Pointers and the Fastest Possible C++ Delegates.

• Sergey Ryazanov: The Impossibly Fast C++ Delegates.

• Quynh Nguyen: A new way to implement Delegate in C++.

3.   IMPLEMENTATIONS

To make those obscured concepts above clearer, I would go into some detailed implementations of signals & slots with the emphasize on the sigslot library, for this is really a compact lib: everything is contained in just one header file. Suppose you have a server that would receive some signal from network (tcp socket), then parse the received data and trigger some processing (display on GUI, store to disk…). We would define the “network signal” as follow (please note any number of parameters can be defined, we use an int and a char* here just for the example):

Then, at the place you want to process that event, e.g some class CDisplayForm, you would need to provide a function to process the signal:

Please note that multiple objects can register to a same signal slot (and vice versa), e.g some class CRecordThread would also need to log that event to database. Then the listening objects would just register with the signal slot using a connect function:

When the network signal arrive, e.g in some class CAsyncSocket, we would fire the signal and get it populated to all connected objects:

Then the CDisplayForm and CRecordThread object would both receive the signal. Please note that when either end of the communication channel go out of scope, the connection is automatically removed, you don’t have to write any cleanup code. Just define the signal, the slot and wire them up! Any unrelated classes can be wired up in this type-safe manner without any pre-defined relation within them.

his is among the most interesting things I’ve ever worked on: Ipix’s CommandView™: fish-eye cameras which provide a 360° x 180° field of vision. This camera and it’s technology were very special and advanced at the time, about 3, 4 years ago, it were so new that the manufacturer could not survive the small market share and went bankruptcy. However, the technology has now revired at http://www.ipix.com. The camera came with some totally new concepts, patents and technologies. Some information on Ipix:

• History of the company, bankruptcy, and how Sony purchased Ipix’s patents.
• Conflicts with open source sofware and controversies over the patents.
• Some examples on uses of the camera: sightseeing, and real-estate.

Ceiling or wall-mounted, with thick hard steel cover, the camera is designed to operate indoor or outdoor, and can withstand a temperature range from -40°C to 60°C. It costs about $2100 at the current time, and about $5000 when it first appeared. CommandView™ Dome is an IP camera, having a small Linux computer inside, once plugged onto LAN or WAN, the camera turns into a video server and can stream video in many protocols: http, ftp, rtp, or multicast. There’re 3 ways to control the camera: ssh to the Linux machine, access to it’s web-server or programatically use the XML-RPC interface. The product has a very matured and solid development flatform.

CommandView™ Dome is a mega-pixel camera (2 MB, 3 MB). The unique feature of this product is that it provides a 360° x 180° field of view with no moving parts. See the image beside (on the left – click to view a mega-pixel version), every details in the room is captured on a parabolic sphere (called wrapped image). To have a normal view, a region on the sphere is dewrapped (by software) into usual rectangular plane.

Since a whole 360° space is captured, PTZ (pan / tilt / zoom) is just a matter of dewrapping, there’s no need to motorize the camera for different sighting fields. This special camera has broadened the definition of ‘panorama’ and has many applications in security surveillance as well as photography. I myself found it very interesting to apply the concepts and softwares to demonstration and show-case purposes (search for ‘ipix’, the name has gone far beyond just a type of camera).