Signals and slots are loosely coupled: A class which emits a signal neither knows nor cares which slots receive the signal. Qt's signals and slots mechanism ensures that if you connect a signal to a slot, the slot will be called with the signal's parameters at the right time. Signals and slots can take any number of arguments of any type. How does the behaviour differ for direct and queued signal-slot connections? What changes if we emit the object by value or receive it by value? Nearly every customer asks this question at some point in a project. The Qt documentation doesn't say a word about it.
How often is a an object copied, if it is emitted by a signal as a const reference and received by a slot as a const reference? How does the behaviour differ for direct and queued signal-slot connections? What changes if we emit the object by value or receive it by value?
Nearly every customer asks this question at some point in a project. The Qt documentation doesn't say a word about it. There is a good discussion on stackoverflow, which unfortunately leaves it to the reader to pick the right answer from all the answers and comments. So, let's have a systematic and detailed look at how arguments are passed to signals and slots.
Signals and Slots in PySide. From Qt Wiki (Redirected from Signals and slots in PySide) Redirect page. Redirect to: Qt for Python Signals and Slots.
- Nd the index of the signal and of the slot Keep in an internal map which signal is connected to what slots When emitting a signal, QMetaObject::activate is called. It calls qt metacall (generated by moc) with the slot index which call the actual slot.
- There are many problems with them. Qt offer new event-handling system - signal-slot connections. Imagine alarm clock. When alarm is ringing, signal is sending (emitting). And you're handling it as a slot. Every QObject class may have as many signals of slots as you want. You can emit signal only from that class, where signal is.
Setting the Stage
For our experiments, we need a copyable class that we will pass by const reference or by value to signals and slots. The class – let's call it Copy – looks as follows.
The copy constructor and the assignment operator simply perform a member-wise copy – like the compiler generated versions would do. We implement them explicitly to set breakpoints or to print debugging messages. The default constructor is only required for queued connections. We'll learn the reason later.
We need another class, MainView, which ultimately derives from QObject. MainView provides the following signals and slots.
MainView provides four signal-slot connections for each connection type.
The above code is used for direct connections. For queued connections, we comment out the first line and uncomment the second and third line.
The code for emitting the signals looks as follows:
Direct Connections
sendConstRef => receiveConstRef
We best set breakpoints in the copy constructor and assignment operator of the Copy class. If our program only calls emit sendConstRef(c), the breakpoints are not hit at all. So, no copies happen. Why?
The result is not really surprising, because this is exactly how passing arguments as const references in C++ works and because a direct signal-slot connection is nothing else but a chain of synchronous or direct C++ function calls.
Nevertheless, it is instructive to look at the chain of function calls executed when the sendConstRef signal is emitted.
The meta-object code of steps 2, 3 and 4 – for marshalling the arguments of a signal, routing the emitted signal to the connected slots and de-marshalling the arguments for the slot, respectively – is written in such a way that no copying of the arguments occurs. This leaves us with two places, where copying of a Copy object could potentially occur: when passing the Copy object to the functions MainView::sendConstRef or MainView::receiveConstRef.
These two places are governed by standard C++ behaviour. Copying is not needed, because both functions take their arguments as const references. There are also no life-time issues for the Copy object, because receiveConstRef returns before the Copy object goes out of scope at the end of sendConstRef.
sendConstRef => receiveValue
Based on the detailed analysis in the last section, we can easily figure out that only one copy is needed in this scenario. When qt_static_meta_call calls receiveValue(Copy c) in step 4, the original Copy object is passed by value and hence must be copied.
sendValue => receiveConstRef
One copy happens, when the Copy object is passed by value to sendValue by value.
sendValue => receiveValue
This is the worst case. Two copies happen, one when the Copy object is passed to sendValue by value and another one when the Copy object is passed to receiveValue by value.
Queued Connections
A queued signal-slot connection is nothing else but an asynchronous function call. Conceptually, the routing function QMetaObject::activate does not call the slot directly any more, but creates a command object from the slot and its arguments and inserts this command object into the event queue. When it is the command object's turn, the dispatcher of the event loop will remove the command object from the queue and execute it by calling the slot.
When QMetaObject::activate creates the command object, it stores a copy of the Copy object in the command object. Therefore, we have one extra copy for every signal-slot combination.
We must register the Copy class with Qt's meta-object system with the command qRegisterMetaType('Copy'); in order to make the routing of QMetaObject::activate work. Any meta type is required to have a public default constructor, copy constructor and destructor. That's why Copy has a default constructor.
Queued connections do not only work for situations where the sender of the signal and the receiver of the signal are in the same thread, but also when the sender and receiver are in different threads. Even in a multi-threaded scenario, we should pass arguments to signals and slots by const reference to avoid unnecessary copying of the arguments. Qt makes sure that the arguments are copied before they cross any thread boundaries.
Conclusion
The following table summarises our results. The first line, for example, reads as follows: If the program passes the argument by const reference to the signal and also by const reference to the slot, there are no copies for a direct connection and one copy for a queued connection.
| Signal | Slot | Direct | Queued |
|---|---|---|---|
| const Copy& | const Copy& | 0 | 1 |
| const Copy& | Copy | 1 | 2 |
| Copy | const Copy& | 1 | 2 |
| Copy | Copy | 2 | 3 |
The conclusion from the above results is that we should pass arguments to signals and slots by const reference and not by value. This advice is true for both direct and queued connections. Even if the sender of the signal and the receiver of the slot are in different threads, we should still pass arguments by const reference. Qt takes care of copying the arguments, before they cross the thread boundaries – and everything is fine.
By the way, it doesn't matter whether we specify the argument in a connect call as const Copy& or Copy. Qt normalises the type to Copy any way. This normalisation does not imply, however, that arguments of signals and slots are always copied – no matter whether they are passed by const reference or by value.
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.
One simple thought about the basics
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. New casino slot machines for sale. 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.
The meta-object code of steps 2, 3 and 4 – for marshalling the arguments of a signal, routing the emitted signal to the connected slots and de-marshalling the arguments for the slot, respectively – is written in such a way that no copying of the arguments occurs. This leaves us with two places, where copying of a Copy object could potentially occur: when passing the Copy object to the functions MainView::sendConstRef or MainView::receiveConstRef.
These two places are governed by standard C++ behaviour. Copying is not needed, because both functions take their arguments as const references. There are also no life-time issues for the Copy object, because receiveConstRef returns before the Copy object goes out of scope at the end of sendConstRef.
sendConstRef => receiveValue
Based on the detailed analysis in the last section, we can easily figure out that only one copy is needed in this scenario. When qt_static_meta_call calls receiveValue(Copy c) in step 4, the original Copy object is passed by value and hence must be copied.
sendValue => receiveConstRef
One copy happens, when the Copy object is passed by value to sendValue by value.
sendValue => receiveValue
This is the worst case. Two copies happen, one when the Copy object is passed to sendValue by value and another one when the Copy object is passed to receiveValue by value.
Queued Connections
A queued signal-slot connection is nothing else but an asynchronous function call. Conceptually, the routing function QMetaObject::activate does not call the slot directly any more, but creates a command object from the slot and its arguments and inserts this command object into the event queue. When it is the command object's turn, the dispatcher of the event loop will remove the command object from the queue and execute it by calling the slot.
When QMetaObject::activate creates the command object, it stores a copy of the Copy object in the command object. Therefore, we have one extra copy for every signal-slot combination.
We must register the Copy class with Qt's meta-object system with the command qRegisterMetaType('Copy'); in order to make the routing of QMetaObject::activate work. Any meta type is required to have a public default constructor, copy constructor and destructor. That's why Copy has a default constructor.
Queued connections do not only work for situations where the sender of the signal and the receiver of the signal are in the same thread, but also when the sender and receiver are in different threads. Even in a multi-threaded scenario, we should pass arguments to signals and slots by const reference to avoid unnecessary copying of the arguments. Qt makes sure that the arguments are copied before they cross any thread boundaries.
Conclusion
The following table summarises our results. The first line, for example, reads as follows: If the program passes the argument by const reference to the signal and also by const reference to the slot, there are no copies for a direct connection and one copy for a queued connection.
| Signal | Slot | Direct | Queued |
|---|---|---|---|
| const Copy& | const Copy& | 0 | 1 |
| const Copy& | Copy | 1 | 2 |
| Copy | const Copy& | 1 | 2 |
| Copy | Copy | 2 | 3 |
The conclusion from the above results is that we should pass arguments to signals and slots by const reference and not by value. This advice is true for both direct and queued connections. Even if the sender of the signal and the receiver of the slot are in different threads, we should still pass arguments by const reference. Qt takes care of copying the arguments, before they cross the thread boundaries – and everything is fine.
By the way, it doesn't matter whether we specify the argument in a connect call as const Copy& or Copy. Qt normalises the type to Copy any way. This normalisation does not imply, however, that arguments of signals and slots are always copied – no matter whether they are passed by const reference or by value.
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.
One simple thought about the basics
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. New casino slot machines for sale. 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.
Qt Signals Slots Emit In The Dark
Wrap up
Qt Signals Slots Emit Waves
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.
