Introduction
Hi, I am working with an extra workerthread in Qt which communicates with the mainwindow via Signals and Slots. This works fine so far. Now I want to send a signal containing 2 arrays from my workerthread to the mainwindow, which doesn't really work. So far, I have already understood the signal and slots on high level abstraction. However, this 'emit' pseudo-keyword is really confusing for novice guy like me. Some said its a syntactic sugar, some said there is a moc -object that works with emit. I wanted to know how,where, when, why to apply this emit pseudo -keyword.
Remember old X-Windows call-back system? Generally it isn't type safe and flexible. There are many problems with them. Qt offers a new event handling system: signal-slot connections. Imagine an alarm clock. When alarm is ringing, a signal is being sent (emit). And you're handling it in a slot.
- Every QObject class may have as many signals and slots as you want
- You can emit signals only from within that class, where the signal is located
- You can connect signal with another signal (make chains of signals);
- Every signal and slot can have unlimited count of connections with other.
- ATTENTION! You can't set default value in slot attributes e.g. void mySlot(int i = 0);
Connection
You can connect signal with this template:
QObject::connect (
);
You have to wrap const char * signal and const char * method into SIGNAL() and SLOT() macros.
And you also can disconnect signal-slot:
QObject::disconnect (
);
Deeper
Widgets emit signals when events occur. Poker odds calculator texas holdem. For example, a button will emit a clicked signal when it is clicked. A developer can choose to connect to a signal by creating a function (a slot) and calling the connect() function to relate the signal to the slot. Qt's signals and slots mechanism does not require classes to have knowledge of each other, which makes it much easier to develop highly reusable classes. Since signals and slots are type-safe, type errors are reported as warnings and do not cause crashes to occur.
For example, if a Quit button's clicked() signal is connected to the application's quit() slot, a user's click on Quit makes the application terminate. In code, this is written as
connect(button, SIGNAL (clicked()), qApp, SLOT (quit()));
Connections can be added or removed at any time during the execution of a Qt application, they can be set up so that they are executed when a signal is emitted or queued for later execution, and they can be made between objects in different threads.
The signals and slots mechanism is implemented in standard C++. The implementation uses the C++ preprocessor and moc, the Meta Object Compiler, included with Qt. Code generation is performed automatically by Qt's build system. Developers never have to edit or even look at the generated code.
In addition to handling signals and slots, the Meta Object Compiler supports Qt's translation mechanism, its property system, and its extended runtime type information. It also makes runtime introspection of C++ programs possible in a way that works on all supported platforms.
To make moc compile the meta object classes don't forget to add the Q_OBJECT macro to your class.
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.
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
. Poker online deutsch kostenlos spielen.
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.
Qt Signals Slots Emit Waves
sendValue => receiveValue
Qt Signal Slot Emit Example
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.
Qt Signal Slot Emit Example
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.