I believe the signal/slot mechanism has found its soul mate in C11 lambda functions. What’s this signal/slot thingy? If you don’t work in Qt you probably don’t care anyway but the fundamental communication mechanism between objects in the Qt framework is defined by signals (events that can be emitted) and slots (handlers for events).

1. Qt Signals And Slots Lambda
2. Qt Signal Slot Lambda Functions Diagram

1. Qt - Dealing with Databases; Qt Container Classes; Qt Network; Qt Resource System; QTimer; Basic Usage; QTimer::singleShot simple usage; Simple example; Singleshot Timer with Lambda function as slot; Using QTimer to run code on main thread; Signals and Slots; SQL on Qt; Threading and Concurrency; Using Style Sheets Effectively.
2. A lambda is essentially a call to an anonymous function, with nasty syntax. If you wrote your slot as a function, you would pass a parameter for the string (received from the signal) to it, wouldn't you?

Introduction

Remarks

Official documentation on this topic can be found here.

A Small Example

Signals and slots are used for communication between objects. The signals and slots mechanism is a central feature of Qt and probably the part that differs most from the features provided by other frameworks.

The minimal example requires a class with one signal, one slot and one connection:

counter.h

The main sets a new value. We can check how the slot is called, printing the value.

Finally, our project file:

Connecting overloaded signals/slots

While being better in many regards, the new connection syntax in Qt5 has one big weakness: Connecting overloaded signals and slots. In order to let the compiler resolve the overloads we need to use static_casts to member function pointers, or (starting in Qt 5.7) qOverload and friends:

Multi window signal slot connection

A simple multiwindow example using signals and slots.

There is a MainWindow class that controls the Main Window view. A second window controlled by Website class.

The two classes are connected so that when you click a button on the Website window something happens in the MainWindow (a text label is changed).

I made a simple example that is also on GitHub:

mainwindow.h

mainwindow.cpp

website.h

website.cpp

Project composition:

Consider the Uis to be composed:

• Main Window: a label called 'text' and a button called 'openButton'
• Website Window: a button called 'changeButton'

So the keypoints are the connections between signals and slots and the management of windows pointers or references.

The new Qt5 connection syntax

The conventional connect syntax that uses SIGNAL and SLOT macros works entirely at runtime, which has two drawbacks: it has some runtime overhead (resulting also in binary size overhead), and there's no compile-time correctness checking. The new syntax addresses both issues. Before checking the syntax in an example, we'd better know what happens in particular.

Let's say we are building a house and we want to connect the cables. This is exactly what connect function does. Signals and slots are the ones needing this connection. The point is if you do one connection, you need to be careful about the further overlaping connections. Whenever you connect a signal to a slot, you are trying to tell the compiler that whenever the signal was emitted, simply invoke the slot function. This is what exactly happens.

Here's a sample main.cpp:

Hint: the old syntax (SIGNAL/SLOT macros) requires that the Qt metacompiler (MOC) is run for any class that has either slots or signals. From the coding standpoint that means that such classes need to have the Q_OBJECT macro (which indicates the necessity to run MOC on this class).

The new syntax, on the other hand, still requires MOC for signals to work, but not for slots. If a class only has slots and no signals, it need not have the Q_OBJECT macro and hence may not invoke the MOC, which not only reduces the final binary size but also reduces compilation time (no MOC call and no subsequent compiler call for the generated *_moc.cpp file).

The one thing that confuses the most people in the beginning is the Signal & Slot mechanism of Qt. But it’s actually not that difficult to understand. In general Signals & Slots are used to loosely connect classes. Illustrated by the keyword emit, Signals are used to broadcast a message to all connected Slots. If no Slots are connected, the message 'is lost in the wild'. So a connection between Signals & Slots is like a TCP/IP connection with a few exceptions, but this metaphor will help you to get the principle. A Signal is an outgoing port and a Slot is an input only port and a Signal can be connected to multiple Slots.

For me one of the best thins is, that you don’t have to bother with synchronization with different threads. For example you have one QObject that’s emitting the Signal and one QObject receiving the Signal via a Slot, but in a different thread. You connect them via QObject::connect(...) and the framework will deal with the synchronization for you. But there is one thing to keep in mind, if you have an object that uses implicitly sharing (like OpenCV’s cv::Mat) as parameter, you have to deal with the synchronization yourself.The standard use-case of Signals & Slots is interacting with the UI from the code while remaining responsive. This is nothing more than a specific version of 'communicating between threads'.Another benefit of using them is loosely coupled objects. The QObject emitting the Signal does not know the Slot-QObject and vice versa. This way you are able to connect QObjects that are otherwise only reachable via a full stack of pointer-calls (eg. this->objA->...->objZ->objB->recieveAQString()). Alone this can save you hours of work if someone decides to change some structure, eg. the UI.

Right now I only mentioned Signal- & Slot-methods. But you are not limited to methods - at least on the Slots side. You can use lambda functions and function pointers here. This moves some of the convenience from languages like Python or Swift to C++.

For some demonstrations I will use the following classes:

Using Connections

To connect a Signal to a Slot you can simply call QObject::connect(a, &AObject::signalSometing, b, &BObject::recieveAQString) or QObject::connect(a, SIGNAL(signalSometing(QString), b, SLOT(recieveAQString(QString)) if you want to use the 'old' syntax. The main difference is, if you use the new syntax, you have compile-time type-checking and -converting. But one big advantage of the 'old' method is that you don’t need to bother with inheritance and select the most specialized method.Lambdas can be a very efficient way of using Signals & Slots. If you just want to print the value, e.g. if the corresponding property changes, the most efficient way is to use lambdas. So by using lambdas you don’t have to blow up your classes with simple methods. But be aware, that if you manipulate any object inside the lambda you have to keep in mind, that synchronization issues (in a multithreaded environment) might occur.

Qt Signals And Slots Lambda

You will get an idea of how to use the different methods in the following example:

As you see, recived a QString: 'Hello' is printed two times. This happens because we connected the same Signals & Slots two times (using different methods). In the case, you don’t want that, you see some methods to prohibit that and other options in the next section Connection Types.

One side note: if you are using Qt::QueuedConnection and your program looks like the following example, at some point you will probably wonder, why calling the Signal will not call the Slots until app.exec() is called. The reason for this behavior is that the event queue, the Slot-call is enqueued, will start with this call (and block until program exits).

And before we start with the next section here is a little trick to call a method of another thread inside the context of the other thread. This means, that the method will be executed by the other thread and not by the 'calling' one.

To learn more about that here is your source of truth: https://doc.qt.io/qt-5/qmetamethod.html#invoke

Connection Types

Qt::AutoConnection

Qt::AutoConnection is the default value for any QObject::connect(...) call. If both QObjects that are about to be connected are in the same thread, a Qt::DirectConnection is used. But if one is in another thread, a Qt::QueuedConnection is used instead to ensure thread-safety. Please keep in mind, if you have both QObjects in the same thread and connected them the connection type is Qt::DirectConnection, even if you move one QObject to another thread afterwards. I generally use Qt::QueuedConnection explicitly if I know that the QObjects are in different threads.

Qt::DirectConnection

A Qt::DirectConnection is the connection with the most minimal overhead you can get with Signals & Slots. You can visualize it that way: If you call the Signal the method generated by Qt for you calls all Slots in place and then returns.

Qt::QueuedConnection

Qt Signal Slot Lambda Functions Diagram

The Qt::QueuedConnection will ensure that the Slot is called in the thread of the corresponding QObject. It uses the fact, that every thread in Qt (QThread) has a Event-queue by default. So if you call the Signal of the QObject the method generated by Qt will enqueue the command to call the Slot in the Event-queue of the other QObjects thread. The Signal-method returns immediately after enqueuing the command. To ensure all parameters exist within the other threads scope, they have to be copied. The meta-object system of Qt has to know all of the parameter types to be capable of that (see qRegisterMetaType).

Qt::BlockingQueuedConnection

A Qt::BlockingQueuedConnection is like a Qt::QueuedConnection but the Signal-method will block until the Slot returns. If you use this connection type on QObjects that are in the same thread you will have a deadlock. And no one likes deadlocks (at least I don’t know anyone).

Qt::UniqueConnection

Qt::UniqueConnection is not really a connection type but a modifier. If you use this flag you are not able to connect the same connection again. But if you try it QObject::connect(...) will fail and return false.

This is not everything you will ever need to know about Signals & Slots but with this information you can cover about 80% of all use-cases (in my opinion).If it happens and you need the other 20% of information, I’ll give you some good links to search your specific problem on:

The Qt documentation:

Very deep understanding:

Part1: https://woboq.com/blog/how-qt-signals-slots-work.html

Part2: https://woboq.com/blog/how-qt-signals-slots-work-part2-qt5.html

Part3: https://woboq.com/blog/how-qt-signals-slots-work-part3-queuedconnection.html

< previous step index next step >