Qt Signals Slots Emit

Qt Signals Slots Emit

Introduction 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. Signals are emitted by objects when they change their state in a way that may be interesting to other objects. Slots can be used for receiving signals, but they are also normal member functions. 
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. In this case if you emit a signal from one thread, and catching it in another one (e.g. In main GUI thread) - Qt will put a slot's call to the message queue and will make all calls sequentially. Read this for further info - http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads.

RemarksOfficial documentation on this topic can be found here.
A Small ExampleSignals 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 connectionA 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: Aristocrat poker machine parts.
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 syntaxThe 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).
Qt中的类库有接近一半是从基类QObject上继承下来，信号与反应槽（signals/slot）机制就是用来在QObject类或其子类间通讯的方法。作为一种通用的处理机制，信号与反应槽非常灵活，可以携带任意数量的参数，参数的类型也由用户自定。同时其本身也是类型安全的，任何一个从QObject或其子类继承的用户类都可以使用信号与反应槽。
 信号的作用如同Windows系统中的消息。在Qt中，对于发出信号的对象来说，它并不知道是谁接收了这个信号。这样的设计可能在某些地方会有些不便，但却杜绝了紧耦合，于总体设计有利。反应槽是用来接收信号的， 但它实际上也是普通的函数，程序员可以象调用普通函数一样来调用反应槽。与信号类似的是，反应槽的拥有者也不知道是谁向它发出了信号。在程序设计过程中，多个信号可以连接至一个反应槽，类似的，一个信号也可以连接至多个反应槽，甚至一个信号可以连接至另一个信号。
 在Windows中，如果我们需要多个菜单都激发一个函数，一般是先写一个共用函数，然后在每个菜单的事件中调用此函数。在Qt中如果要实现同样的功能，就可以把实现部分写在一个菜单中，然后把其他菜单与这个菜单级联起来。
 虽然信号/反应槽机制有很多优点，使用也很方便，但它也不是没有缺点。最大的缺点在于要稍微牺牲一点性能。根据Trolltech公司的自测，在CPU为Intel PentiumII 500 Mhz的PC机上，对于一个信号对应一个反应槽的连接来说，一秒钟可以调用两百万次；对于一个信号对应两个反应槽的连接来说，一秒钟可以调用一百二十万次。这个速度是不经过连接而直接进行回调的速度的十分之一。请注意这里的十分之一速度比是调用速度的比较，而不是一个完整函数执行时间的比较。事实上一般情况下一个函数的总执行时间大部分是在执行部分，只有小部分是在调用部分，因些这个速度是可以接受的。这就象面向对象的编程和早些年的结构化编程相比一样：
程序的执行效率并没有提高，反而是有所下降的，但现在大家都在用面向对象的方法编写程序。用一部分执行效率换回开发效率与维护效率是值得的，况且现在已是P4为主流的时代。
 我们先来看一个简单的样例：
 在以上程序中，一旦信号与反应槽连接，当执行a.setValue(79)时就会释放出一个valueChanged(int)的信号，对象b将会收到这个信号并触发setValue(int)这个函数。当b在执行setValue(int)这个函数时，它也将释放valueChanged(int)这个信号，当然b的信号无人接收，因此就什么也没干。请注意，在样例中我们仅当输入变量v不等于val时才释放信号，因此就算对a与b进行了交叉连接也不会导致死循环的发生。由于在样例中使用了Qt特有的关键字和宏，而Qt本身并不包括C++的编译器，因此如果用流行的编译程序（如Windows下的Visual C++或Linux下的gcc）是不能直接编译这段代码的，必须用Qt的中间编译工具moc.exe把该段代码转换为无专用关键字和宏的C++代码才能为这些编译程序所解析、编译与链接。
 以上代码中信号与反应槽的定义是在类中实现的。那么，非类成员的函数，比如说一个全局函数可不可以也这样做呢？答案是不行，只有是自身定义了信号的类或其子类才可以发出该种信号。一个对象的不同信号可以连接至不同的对象。当一个信号被释放时，与之连接的反应槽将被立刻执行，就象是在程序中直接调用该函数一样。信号的释放过程是阻塞的，这意味着只有当反应槽执行完毕后该信号释放过程才返回。如果一个信号与多个反应槽连接，则这些反应槽将被顺序执行，排序过程则是任意的。因此如果程序中对这些反应槽的先后执行次序有严格要求的，应特别注意。使用信号时还应注意：信号的定义过程是在类的定义过程即头文件中实现的。为了中间编译工具moc的正常运行，不要在源文件(.cpp)中定义信号，同时信号本身不应返回任何数据类型，即是空值(void)。如果你要设计一个通用的类或控件，则在信号或反应槽的参数中应尽可能使用常规数据以增加通用性。如上例代码中valueChanged的参数为int型，如果它使用了特殊类型如QRangeControl::Range，那么这种信号只能与RangeControl中的反应槽连接。如前所述，反应槽也是常规函数，与未定义slots的用户函数在执行上没有任何区别。
 但在程序中不可把信号与常规函数连接在一起，否则信号的释放不会引起对应函数的执行。要命的是中间编译程序moc并不会对此种情况报错，C++编译程序更不会报错。初学者比较容易忽略这一点，往往是程序编好了没有错误，逻辑上也正确，但运行时就是不按自己的意愿出现结果，这时候应检查一下是不是这方面的疏忽。
 Qt的设计者之所以要这样做估计是为了信号与反应槽之间匹配的严格性。既然反应槽与常规函数在执行时没有什么区别，因此它也可以定义成公共反应槽（public slots）、保护反应槽（protected slots）和私有反应槽（private slots）。如果需要，我们也可以把反应槽定义成虚函数以便子类进行不同的实现，这一点是非常有用的。

Introduction 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. Signals are emitted by objects when they change their state in a way that may be interesting to other objects. Slots can be used for receiving signals, but they are also normal member functions. 
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. In this case if you emit a signal from one thread, and catching it in another one (e.g. In main GUI thread) - Qt will put a slot's call to the message queue and will make all calls sequentially. Read this for further info - http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads.
RemarksOfficial documentation on this topic can be found here.
A Small ExampleSignals 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/slotsWhile 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 connectionA 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: Aristocrat poker machine parts.
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 syntaxThe 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).
Qt中的类库有接近一半是从基类QObject上继承下来，信号与反应槽（signals/slot）机制就是用来在QObject类或其子类间通讯的方法。作为一种通用的处理机制，信号与反应槽非常灵活，可以携带任意数量的参数，参数的类型也由用户自定。同时其本身也是类型安全的，任何一个从QObject或其子类继承的用户类都可以使用信号与反应槽。
 信号的作用如同Windows系统中的消息。在Qt中，对于发出信号的对象来说，它并不知道是谁接收了这个信号。这样的设计可能在某些地方会有些不便，但却杜绝了紧耦合，于总体设计有利。反应槽是用来接收信号的， 但它实际上也是普通的函数，程序员可以象调用普通函数一样来调用反应槽。与信号类似的是，反应槽的拥有者也不知道是谁向它发出了信号。在程序设计过程中，多个信号可以连接至一个反应槽，类似的，一个信号也可以连接至多个反应槽，甚至一个信号可以连接至另一个信号。
 在Windows中，如果我们需要多个菜单都激发一个函数，一般是先写一个共用函数，然后在每个菜单的事件中调用此函数。在Qt中如果要实现同样的功能，就可以把实现部分写在一个菜单中，然后把其他菜单与这个菜单级联起来。
 虽然信号/反应槽机制有很多优点，使用也很方便，但它也不是没有缺点。最大的缺点在于要稍微牺牲一点性能。根据Trolltech公司的自测，在CPU为Intel PentiumII 500 Mhz的PC机上，对于一个信号对应一个反应槽的连接来说，一秒钟可以调用两百万次；对于一个信号对应两个反应槽的连接来说，一秒钟可以调用一百二十万次。这个速度是不经过连接而直接进行回调的速度的十分之一。请注意这里的十分之一速度比是调用速度的比较，而不是一个完整函数执行时间的比较。事实上一般情况下一个函数的总执行时间大部分是在执行部分，只有小部分是在调用部分，因些这个速度是可以接受的。这就象面向对象的编程和早些年的结构化编程相比一样：
程序的执行效率并没有提高，反而是有所下降的，但现在大家都在用面向对象的方法编写程序。用一部分执行效率换回开发效率与维护效率是值得的，况且现在已是P4为主流的时代。
 我们先来看一个简单的样例：
 在以上程序中，一旦信号与反应槽连接，当执行a.setValue(79)时就会释放出一个valueChanged(int)的信号，对象b将会收到这个信号并触发setValue(int)这个函数。当b在执行setValue(int)这个函数时，它也将释放valueChanged(int)这个信号，当然b的信号无人接收，因此就什么也没干。请注意，在样例中我们仅当输入变量v不等于val时才释放信号，因此就算对a与b进行了交叉连接也不会导致死循环的发生。由于在样例中使用了Qt特有的关键字和宏，而Qt本身并不包括C++的编译器，因此如果用流行的编译程序（如Windows下的Visual C++或Linux下的gcc）是不能直接编译这段代码的，必须用Qt的中间编译工具moc.exe把该段代码转换为无专用关键字和宏的C++代码才能为这些编译程序所解析、编译与链接。
 以上代码中信号与反应槽的定义是在类中实现的。那么，非类成员的函数，比如说一个全局函数可不可以也这样做呢？答案是不行，只有是自身定义了信号的类或其子类才可以发出该种信号。一个对象的不同信号可以连接至不同的对象。当一个信号被释放时，与之连接的反应槽将被立刻执行，就象是在程序中直接调用该函数一样。信号的释放过程是阻塞的，这意味着只有当反应槽执行完毕后该信号释放过程才返回。如果一个信号与多个反应槽连接，则这些反应槽将被顺序执行，排序过程则是任意的。因此如果程序中对这些反应槽的先后执行次序有严格要求的，应特别注意。使用信号时还应注意：信号的定义过程是在类的定义过程即头文件中实现的。为了中间编译工具moc的正常运行，不要在源文件(.cpp)中定义信号，同时信号本身不应返回任何数据类型，即是空值(void)。如果你要设计一个通用的类或控件，则在信号或反应槽的参数中应尽可能使用常规数据以增加通用性。如上例代码中valueChanged的参数为int型，如果它使用了特殊类型如QRangeControl::Range，那么这种信号只能与RangeControl中的反应槽连接。如前所述，反应槽也是常规函数，与未定义slots的用户函数在执行上没有任何区别。
 但在程序中不可把信号与常规函数连接在一起，否则信号的释放不会引起对应函数的执行。要命的是中间编译程序moc并不会对此种情况报错，C++编译程序更不会报错。初学者比较容易忽略这一点，往往是程序编好了没有错误，逻辑上也正确，但运行时就是不按自己的意愿出现结果，这时候应检查一下是不是这方面的疏忽。
 Qt的设计者之所以要这样做估计是为了信号与反应槽之间匹配的严格性。既然反应槽与常规函数在执行时没有什么区别，因此它也可以定义成公共反应槽（public slots）、保护反应槽（protected slots）和私有反应槽（private slots）。如果需要，我们也可以把反应槽定义成虚函数以便子类进行不同的实现，这一点是非常有用的。
 只讨论一下信号与反应槽的使用好象还不过瘾，既然Qt的X11 Free版提供了源代码，我们就进去看一下在QObject中connect的实现。由于Qt是一个跨平台的开发库，为了与不同平台上的编译器配合，它定义了一个中间类QMetaObject，该类的作用是存放有关信号/反应槽以及对象自身的信息。这个类是Qt内部使用的，用户不应去使用它。
Qt Signals Slots Emit Sound 再看一下QObject中connect的实现。剥去粗枝，函数中便露出一个更细化的函数：connectInternal，它又做了哪些工作呢？让我们看一下：
 到此，信号与反应槽的连接已建立完毕，那么信号产生时又是如何触发反应槽的呢？从QObject的定义中可以看出其有多个activate_signal的成员函数，这些函数都是protected的，也即只有其自身或子类才可以使用。看一下它的实现：
 至此我们已经可以基本了解Qt中信号/反应槽的流程。我们再看一下Qt为此而新增的语法：三个关键字：slots、signals和emit，三个宏：SLOT()、SIGNAL()和Q_OBJECT。在头文件qobjectdefs.h中，我们可以看到这些新增语法的定义如下：
 由此可知其实三个关键字没有做什么事情，而SLOT()和SIGNAL()宏也只是在字符串前面简单地加上单个字符，以便程序仅从名称就可以分辨谁是信号、谁是反应槽。中间编译程序moc.exe则可以根据这些关键字和宏对相应的函数进行'翻译'，以便在C++编译器中编译。剩下一个宏Q_OBJECT比较复杂，它的定义如下：
 从定义中可以看出该宏的作用有两个：一是对与自己相关的QMetaObject中间类操作进行声明，另一个是对信号的释放操作和反应槽的激活操作进行声明。当moc.exe对头文件进行预编译之后，将会产生一个可供C++编译器编译的源文件。以上述的Demo类为例，假设它的代码文件分别为demo.h和demo.cpp，预编译后将产生moc_demo.cpp，其主要内容如下：
该文件中既没有Qt特有的关键字，也没有特殊的宏定义，完全符合普通的C++语法，因此可以顺利编译和链接。
Qt Signals Slots Emit Wavesposted @ 2016-12-22 17:44FelixWang 阅读(71186) 评论(0) 编辑收藏