Signals and slots were one of the distinguishing features that made Qt an exciting and innovative tool back in time. But sometimes you can teach new tricks to an old dog, and QObjects gained a new way to connect between signals and slots in Qt5, plus some extra features to connect to other functions which are not slots. Let’s review how to get the most of that feature. This assumes you are already moderately familiar with signals and slots.

• Signal Slot Qt With Param
• Signal Slot Editor Qt Designer
• Signal Slot In Thread Qt
• Signal Slot Qt
• Signal And Slot In Qt Library
• How Signal Slot Works In Qt

One simple thought about the basics

See full list on doc.qt.io. 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. Signals and slots are used for communication between objects. The signals and slots mechanism is a central feature of Qt. In GUI programming, when we change one widget, we often want another widget to be notified. More generally, we want objects of any kind to be able to communicate with one another. In Qt, we have an alternative to the callback technique: We use signals and slots. A signal is emitted when a particular event occurs. Qt's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them. A slot is a function that is called in response to a particular signal.

I am not going to bore you with repeating basic knowledge you already have, but I want you to look at signals and slots from a certain angle, so it will be easier to understand the design of the feature I will cover next. What’s the purpose of signals and slots? It’s a way in which “one object” makes sure that when “something happened”, then “other object” “reacts to something happened”. As simple as that. That can be expressed in pseudocode like this:

Notice that the four phrases that are into quotes in the previous paragraph are the four arguments of the function call in the pseudocode. Notice also that one typical way to write the connect statement is aligning the arguments like this, because then the first column (first and third arguments) are object instances that answer “where?” and the second column (second and fourth arguments) are functions that answer “what?”.

In C++ instead of pseudocode, and using real life objects and classes, this would look like this in Qt4 or earlier:

That could be a typical statement from a “Hello World” tutorial, where a button is created and shown, and when it’s pressed the whole window closes and the application terminates.

Now to the main point that I want you to notice here. This has a very subtle advantage over a typical mechanism used in standard C or C++ 11 like callbacks with function pointers and lambda functions wrapped in std::function, and is subtle only because is so nice we often forget about it when we have used signals and slots for a while. If the sender object is destroyed, it obviously can not emit any signal because it is a member function of its class. But for the sender to call the receiver, it needs a pointer to it, and you as a user, don’t need to worry at all about the receiver being destroyed and becoming invalid (that is done automatically by the library), so you very rarely need to call QObject::disconnect.

So signals and slots are very safe by default, and in an automatic way.

The new versus the old way to use connect

The previous example shows one way that works across old versions of Qt published so far (Qt 1 to 5). Recently a blog post about porting a tutorial application from Qt 1 to Qt 5.11 has been published, and no porting was needed at all for signals, slots, or the connections! That doesn’t mean the feature is perfect, since a new way to make connections was added, keeping all the previous functionality.

The main problem with the example above is that (as you probably knew, or guessed from being all uppercase) is that SIGNAL and SLOT are macros, and what those macros do is convert to a string the argument passed. This is a problem because any typo in what gets passed to those means that the call to connect would fail and return false. So since Qt 5.0, a new overload to QObject::connect exists, and supports passing as second and fourth arguments a function pointer to specify which member function should be called. Ported to the new syntax, the above example is:

Now any typo in the name will produce a compile time error. If you misspelled “click” with “clik” in the first example, that would only fail printing a warning in the console when that function gets called. If you did that in some dialog of an application you would have to navigate to that dialog to confirm that it worked! And it would be even more annoying if you were connecting to some error handling, and is not that easy to trigger said error. But if you did the same typo in the last example, it would be a compile time error, which is clearly much better.

This example is usually said to be using the “new syntax”, and the previous example the “old syntax”. Just remember that the old is still valid, but the new is preferred in most situations.

Since this is an exciting new feature added to a new major version, which has received some extra polishing during the minor releases, many blog posts from other members of the Qt community have been published about it (for example covering implementation details or the issues that could arise when there are arguments involved). I won’t cover those topics again, and instead I will focus on the details that in my experience would be most beneficial for people to read on.

No need to declare members as slots anymore (or almost)

The new syntax allows to call not just a member function declared as slot in the header with public slots: (or with protected or private instead of public), but any kind of function (more on that in the next section). There is still one use case where you would want to declare functions as slots, and that is if you want to make that function usable by any feature that happens at run time. That could be QML, for example.

Connecting to anything callable

Now we can connect to any “callable”, which could be a free standing function, a lambda function or a member function of an object that doesn’t derive from QObject. That looks in code like the following:

But wait, where is that nice symmetry with 2 rows and two columns now?

When you connect to a lambda, there is a receiver object, the lambda itself, but there is no signature to specify since it’s the function call operator (the same would happen to a function object or “functor”, by the way). And when there is a free standing function there is a signature, but there is no instance, so the third and the fourth arguments of the first two calls are somewhat merged. Note that the arguments are still checked at compile time: the signal has no arguments, and the lambda has no arguments either. Both sender and receiver are in agreement.

The example using std::bind requires a bit more explanation if you are not familiar with it. In this case we have the two objects and the two function pointers, which is to be expected for what is wanted. We don’t often think about it like this, but we always need a pointer to call a member function (unless it is static). When it is not used, it is because this is implicit, and this->call() can be shortened to call(). So what std::bind does here is create a callable object that glues together the particular instance that we want with one member function. We could do the same with a lambda:

Note that std::bind is actually much more powerful, and can be very useful when the number of arguments differ. But we will leave that topic to another article.

One common use of the above pattern with std::bind is when you have a class implemented through a data pointer (private implementation or pimpl idiom). If you need a button or a timer to call a member function of the private class that is not going to be a QObject, you can write something like this:

Recovering symmetry, safety and convenience

With the previous examples that nice balance of the four arguments is gone. But we are missing something more important.

What would happen if the lambda of the previous examples would use an invalid pointer? In the very first C++ example we showed a button wanting to close the application. Imagine that the button required to close a dialog, or stop some network request, etc. If the object is destroyed because said dialog is already closed or the request finished long ago, we want to manage that automatically so we don’t use an invalid pointer.

An example. For some reason you show some widget and you need to do some last minute update after it has been shown. It needs to happen soon but not immediately, so you use a timer with a short timeout. And you write

That works, but has a subtle problem. It could be that the widget gets shown and immediately closed. The timer under the scenes doesn’t know that, and it will happily call you, and crash the application. If you made the timer connect to a slot of the widget, that won’t happen: as soon as the dialog goes away, the connection gets broken.

Since Qt 5.2 we can have the best of both worlds, and recover that nice warm feeling of having a well balanced connect statement with two objects and two functions. 🙂

In that Qt version an additional overload was added to QObject::connect, and now there is the possibility to pass as third argument a so called “context object”, and as fourth argument the same variety of callables shown previously. Then the context object serves the purpose of automatically breaking the connection when the context is destroyed. That warranties the problem mentioned is now gone. You can easily handle that there are no longer invalid captures on a lambda.

The previous example is almost as the previous:

Now it is as if the lambda were a slot in your class, because to the timer, the context of the connection is the same.

The only requirement is that said context object has to be a QObject. This is not usually a problem, since you can create and ad-hoc QObject instance and even do simple but useful tricks with it. For example, say that you want to run a lambda only on the first click:

This will delete the ad-hoc QObject guard on the first invocation, and the connection will be automatically broken. The object also has the button as a parent, so it won’t be leaked if the button is never clicked and goes away (it will be deleted as well). You can use any QObject as context object, but the most common case will be to shut down timers, processes, requests, or anything related to what your user interface is doing when some dialog, window or panel closes.

Tip: There are utility classes in Qt to handle the lifetime of QObjects automatically, like QScopedPointer and QObjectCleanupHandler. If you have some part of the application using Qt classes but no UI tightly related to that, you can surely find a way to leverage those as members of a class not based on QObject. It is often stated as a criticism to Qt, that you can’t put QObjects in containers or smart pointers. Often the alternatives do exist and can be as good, if not better (but admittedly this is a matter of taste).

Bonus point: thread safety by thread affinity

The above section is the main goal of this article. The context object can save you crashes, and having to manually disconnect. But there is one additional important use of it: making the signal be delivered in the thread that you prefer, so you can save from tedious and error prone locking.

Again, there is one killer feature of signals and slots that we often ignore because it happens automatically. When one QObject instance is the receiver of a signal, its thread affinity is checked, and by default the signal is delivered directly as a function call when is the same thread affinity of the sender. But if the thread affinity differs, it will be delivered posting an event to the object. The internals of Qt will convert that event to a function call that will happen in the next run of the event loop of the receiver, so it will be in the “normal” thread for that object, and you often can forget about locks entirely. The locks are inside Qt, because QCoreApplication::postEvent (the function used to add the event to the queue) is thread-safe. In case of need, you can force a direct call from different threads, or a queued call from the same thread. Check the fifth argument in the QObject::connect documentation (it’s an argument which defaults to Qt::AutoConection).

Let’s see it in a very typical example.

This shows a class that derives from QRunnable to reimplement the run() function, and that derives from QObject to provide the finished() signal. An instance is created after the user activates a button, and then we show some progress bar and run the task. But we want to notify the user when the task is done (show some message, hide some progress bar, etc.).

In the above example, the third argument (context object) might be forgotten, and the code will compile and run, but it would be a serious bug. It would mean that you would attempt to call into the UI thread from the thread where the task was run (which is a helper thread pool, not the UI thread). This is wrong, and in some cases Qt will nicely warn you that you are using some function from the wrong thread, but if you are not lucky, you will have a mysterious crash.

Wrap up

Signal Slot Qt With Param

Hopefully now you’ve understood why that odd point was made in the introduction section. You don’t have to agree that it is aesthetically pleasing to write the arguments to connect in two rows and two columns, but if you understood the importance of using a context object as a rule of thumb, you probably will find your preferred way to remember if that third argument is needed when you write (or review other’s) code using connect.

This is the sequel of my previous article explaining the implementation details of the signals and slots.In the Part 1, we have seenthe general principle and how it works with the old syntax.In this blog post, we will see the implementation details behind thenew function pointerbased syntax in Qt5.

New Syntax in Qt5

The new syntax looks like this:

Why the new syntax?

Signal Slot Editor Qt Designer

I already explained the advantages of the new syntax in adedicated blog entry.To summarize, the new syntax allows compile-time checking of the signals and slots. It also allowsautomatic conversion of the arguments if they do not have the same types.As a bonus, it enables the support for lambda expressions.

New overloads

There was only a few changes required to make that possible.
The main idea is to have new overloads to QObject::connect which take the pointersto functions as arguments instead of char*

There are three new static overloads of QObject::connect: (not actual code)

The first one is the one that is much closer to the old syntax: you connect a signal from the senderto a slot in a receiver object.The two other overloads are connecting a signal to a static function or a functor object withouta receiver.

They are very similar and we will only analyze the first one in this article.

Pointer to Member Functions

Before continuing my explanation, I would like to open a parenthesis totalk a bit about pointers to member functions.

Here is a simple sample code that declares a pointer to member function and calls it.

Pointers to member and pointers to member functions are usually part of the subset of C++ that is not much used and thus lesser known.
The good news is that you still do not really need to know much about them to use Qt and its new syntax. All you need to remember is to put the & before the name of the signal in your connect call. But you will not need to cope with the ::*, .* or ->* cryptic operators.

These cryptic operators allow you to declare a pointer to a member or access it.The type of such pointers includes the return type, the class which owns the member, the types of each argumentand the const-ness of the function.

You cannot really convert pointer to member functions to anything and in particular not tovoid* because they have a different sizeof.
If the function varies slightly in signature, you cannot convert from one to the other.For example, even converting from void (MyClass::*)(int) const tovoid (MyClass::*)(int) is not allowed.(You could do it with reinterpret_cast; but that would be an undefined behaviour if you callthem, according to the standard)

Pointer to member functions are not just like normal function pointers.A normal function pointer is just a normal pointer the address where thecode of that function lies.But pointer to member function need to store more information:member functions can be virtual and there is also an offset to apply to thehidden this in case of multiple inheritance.
sizeof of a pointer to a member function can evenvary depending of the class.This is why we need to take special care when manipulating them.

Type Traits: QtPrivate::FunctionPointer

Let me introduce you to the QtPrivate::FunctionPointer type trait.
A trait is basically a helper class that gives meta data about a given type.Another example of trait in Qt isQTypeInfo.

What we will need to know in order to implement the new syntax is information about a function pointer.

The template<typename T> struct FunctionPointer will give us informationabout T via its member.

• ArgumentCount: An integer representing the number of arguments of the function.
• Object: Exists only for pointer to member function. It is a typedef to the class of which the function is a member.
• Arguments: Represents the list of argument. It is a typedef to a meta-programming list.
• call(T &function, QObject *receiver, void **args): A static function that will call the function, applying the given parameters.

Qt still supports C++98 compiler which means we unfortunately cannot require support for variadic templates.Therefore we had to specialize our trait function for each number of arguments.We have four kinds of specializationd: normal function pointer, pointer to member function,pointer to const member function and functors.For each kind, we need to specialize for each number of arguments. We support up to six arguments.We also made a specialization using variadic templateso we support arbitrary number of arguments if the compiler supports variadic templates.

The implementation of FunctionPointer lies inqobjectdefs_impl.h.

QObject::connect

The implementation relies on a lot of template code. I am not going to explain all of it.

Here is the code of the first new overload fromqobject.h:

You notice in the function signature that sender and receiverare not just QObject* as the documentation points out. They are pointers totypename FunctionPointer::Object instead.This uses SFINAEto make this overload only enabled for pointers to member functionsbecause the Object only exists in FunctionPointer ifthe type is a pointer to member function.

We then start with a bunch ofQ_STATIC_ASSERT.They should generate sensible compilation error messages when the user made a mistake.If the user did something wrong, it is important that he/she sees an error hereand not in the soup of template code in the _impl.h files.We want to hide the underlying implementation from the user who should not needto care about it.
That means that if you ever you see a confusing error in the implementation details,it should be considered as a bug that should be reported.

We then allocate a QSlotObject that is going to be passed to connectImpl().The QSlotObject is a wrapper around the slot that will help calling it. It alsoknows the type of the signal arguments so it can do the proper type conversion.
We use List_Left to only pass the same number as argument as the slot, which allows connectinga signal with many arguments to a slot with less arguments.

QObject::connectImpl is the private internal functionthat will perform the connection.It is similar to the original syntax, the difference is that instead of storing amethod index in the QObjectPrivate::Connection structure,we store a pointer to the QSlotObjectBase.

The reason why we pass &slot as a void** is only tobe able to compare it if the type is Qt::UniqueConnection.

We also pass the &signal as a void**.It is a pointer to the member function pointer. (Yes, a pointer to the pointer)

Signal Index

We need to make a relationship between the signal pointer and the signal index.
We use MOC for that. Yes, that means this new syntaxis still using the MOC and that there are no plans to get rid of it :-).

MOC will generate code in qt_static_metacallthat compares the parameter and returns the right index.connectImpl will call the qt_static_metacall function with thepointer to the function pointer.

Once we have the signal index, we can proceed like in the other syntax.

The QSlotObjectBase

QSlotObjectBase is the object passed to connectImplthat represents the slot.

Before showing the real code, this is what QObject::QSlotObjectBasewas in Qt5 alpha:

It is basically an interface that is meant to be re-implemented bytemplate classes implementing the call and comparison of thefunction pointers.

Signal Slot In Thread Qt

It is re-implemented by one of the QSlotObject, QStaticSlotObject orQFunctorSlotObject template class.

Fake Virtual Table

Signal Slot Qt

The problem with that is that each instantiation of those object would need to create a virtual table which contains not only pointer to virtual functionsbut also lot of information we do not need such asRTTI.That would result in lot of superfluous data and relocation in the binaries.

In order to avoid that, QSlotObjectBase was changed not to be a C++ polymorphic class.Virtual functions are emulated by hand.

The m_impl is a (normal) function pointer which performsthe three operations that were previously virtual functions. The 're-implementations'set it to their own implementation in the constructor.

Please do not go in your code and replace all your virtual functions by such ahack because you read here it was good.This is only done in this case because almost every call to connectwould generate a new different type (since the QSlotObject has template parameterswich depend on signature of the signal and the slot).

Protected, Public, or Private Signals.

Signals were protected in Qt4 and before. It was a design choice as signals should be emittedby the object when its change its state. They should not be emitted fromoutside the object and calling a signal on another object is almost always a bad idea.

However, with the new syntax, you need to be able take the addressof the signal from the point you make the connection.The compiler would only let you do that if you have access to that signal.Writing &Counter::valueChanged would generate a compiler errorif the signal was not public.

In Qt 5 we had to change signals from protected to public.This is unfortunate since this mean anyone can emit the signals.We found no way around it. We tried a trick with the emit keyword. We tried returning a special value.But nothing worked.I believe that the advantages of the new syntax overcome the problem that signals are now public.

Sometimes it is even desirable to have the signal private. This is the case for example inQAbstractItemModel, where otherwise, developers tend to emit signalfrom the derived class which is not what the API wants.There used to be a pre-processor trick that made signals privatebut it broke the new connection syntax.
A new hack has been introduced.QPrivateSignal is a dummy (empty) struct declared private in the Q_OBJECTmacro. It can be used as the last parameter of the signal. Because it is private, only the objecthas the right to construct it for calling the signal.MOC will ignore the QPrivateSignal last argument while generating signature information.See qabstractitemmodel.h for an example.

More Template Code

The rest of the code is inqobjectdefs_impl.h andqobject_impl.h.It is mostly standard dull template code.

I will not go into much more details in this article,but I will just go over few items that are worth mentioning.

Meta-Programming List

As pointed out earlier, FunctionPointer::Arguments is a listof the arguments. The code needs to operate on that list:iterate over each element, take only a part of it or select a given item.

That is why there isQtPrivate::List that can represent a list of types. Some helpers to operate on it areQtPrivate::List_Select andQtPrivate::List_Left, which give the N-th element in the list and a sub-list containingthe N first elements.

The implementation of List is different for compilers that support variadic templates and compilers that do not.

With variadic templates, it is atemplate<typename... T> struct List;. The list of arguments is just encapsulatedin the template parameters.
For example: the type of a list containing the arguments (int, QString, QObject*) would simply be:

Without variadic template, it is a LISP-style list: template<typename Head, typename Tail > struct List;where Tail can be either another List or void for the end of the list.
The same example as before would be:

ApplyReturnValue Trick

In the function FunctionPointer::call, the args[0] is meant to receive the return value of the slot.If the signal returns a value, it is a pointer to an object of the return type ofthe signal, else, it is 0.If the slot returns a value, we need to copy it in arg[0]. If it returns void, we do nothing.

The problem is that it is not syntaxically correct to use thereturn value of a function that returns void.Should I have duplicated the already huge amount of code duplication: once for the voidreturn type and the other for the non-void?No, thanks to the comma operator.

Signal And Slot In Qt Library

In C++ you can do something like that:

You could have replaced the comma by a semicolon and everything would have been fine.

Where it becomes interesting is when you call it with something that is not void:

There, the comma will actually call an operator that you even can overload.It is what we do inqobjectdefs_impl.h

How Signal Slot Works In Qt

ApplyReturnValue is just a wrapper around a void*. Then it can be usedin each helper. This is for example the case of a functor without arguments:

This code is inlined, so it will not cost anything at run-time.

Conclusion

This is it for this blog post. There is still a lot to talk about(I have not even mentioned QueuedConnection or thread safety yet), but I hope you found thisinterresting and that you learned here something that might help you as a programmer.

Update:The part 3 is available.