Study on the transfer directionality of QT signal and slot mechanism (conclusion is wrong, but can look at the analysis process)

QT has been studying recently due to the needs of the project. Signal and slot mechanism is a feature of QT, which allows the transfer of parameters between the two, in order to achieve communication between the objects. This parameter is present in the parameter list of the signal and in the parameter list of the slot function, respectively. It is important to note that if you bind a slot function to a signal, the number of parameter list elements of the slot function can be less than the number of parameter list elements that are equal to the signal. and the order and type cannot be changed. The missing parameters should be missing from the tail of the signal parameter.

Suddenly today I think of a problem, if an object signals, the internal member variable (non-simple type) as a parameter sent out, the slot function can receive this object, then the slot function can fully manipulate the object? If it can be fully operated, then this signal and groove mechanism is a two-way communication process, that a can trigger b,b and can operate on a, if the operation is not valid, then the mechanism is a one-way communication process, that is, a trigger b,b processing, but cannot reverse write data.

Gossip, let the instance speak

First set up a console application

Creating a header file CustomClasses.h

The code is as follows:

[CPP]View PlainCopy

2. #ifndef Customclasses_h
4. #define Customclasses_h
8. #include <QObject>
12. Class Tperson
14. {
16. Private
18. QString _name;
20. Public
22. Tperson ();
24. void SetName (QString Name);
26. QString GetName ();
28. };
32. Class Tsender: Publicqobject
34. {
36. Q_object
38. Private
40. Tperson _p;
42. Public
44. Tsender ();
46. void Click ();
48. void disp ();
50. Signals:
52. void NewName (Tperson P);
54. };
58. Class Treceiver: Publicqobject
60. {
62. Q_object
64. Public
66. Treceiver ();
68. Public Slots:
70. void Getnewname (Tperson P);
72. };
74. #endif//Customclasses_h

Three classes of Tperson, Tsender, and treceiver are defined here.

Tperson is a very simple class that contains a private member, _name, with a get and set method, respectively.

The Tsender class contains a private Tperson instance _p,click () method that simulates a button click and emits a newname (Tperson p) signal when the Click () method is executed.

The Treceiver class contains a getnewname (Tperson p) slot for receiving newname (Tperson p) signals from Tsender.

Establish the corresponding CustomClasses.cpp

The code is as follows:

[CPP]View PlainCopy

2. #include "CustomClasses.h"
4. #include <QtCore>
6. #include <QObject>
8. Tperson::tperson ()
10. {
12. //  
14. }
16. void Tperson::setname (QString Name)
18. {
20. this->_name=name;
22. }
26. QString Tperson::getname ()
28. {
30. return this->_name;
32. }
36. Tsender::tsender ()
38. {
40. this->_p.setname ("Jack");
42. }
46. void Tsender::click ()
48. {
50. Qdebug () <<"Now begin to send the person";
52. Emit This->newname (this->_p);
54. Qdebug () <<"person with sended";
56. }
60. void Tsender::d ISP ()
62. {
64. Qdebug () <<"Current person name is:" <<this->_p.getname ();
66. }
70. Treceiver::treceiver ()
72. {
74. //  
76. }
80. void Treceiver::getnewname (Tperson P)
82. {
84. Qdebug () <<"Receive a person name is:" <<p.getname ();
86. Qdebug () <<"begin to change name";
88. P.setname ("Rose");
90. Qdebug () <<"Finish to change name";
92. }

This file is the implementation of the above content, but it is worth noting that in the implementation of void treceiver::getnewname (Tperson p), the P parameter is manipulated, and the SetName method is called.

Master File main.cpp

The code is as follows:

[CPP]View PlainCopy

2. #include <QtCore/QCoreApplication>
4. #include <QtCore>
6. #include <QObject>
8. #include "CustomClasses.h"
12. int main (int argc, char *argv[])
14. {
16. Qcoreapplication A (argc, argv);
18. Tsender send;
20. Treceiver recv;
22. Qobject::connect (&send, SIGNAL (NewName (Tperson)), &recv, SLOT (Getnewname (Tperson)));
24. Send.disp ();
26. Send.click ();
28. Send.disp ();
30. return a.exec ();
32. }

The code instantiates the Tsender class and the Treceiver class, and binds the newname signal to the Getnewname slot. The code is simple, and the rest is no longer introduced.

Let's look at the running results:

Let's analyze the program. After the send instance and the Recv instance have been declared, the related events are bound. First, look at the Name property of the Tperson class instance _p in the current send object. The first line shows the initial jack, and then calls the Send's click () method, which emits the newname signal, which is received by the Recv Getnewname slot function, which displays the name value of the object currently received. It then calls the SetName method of the receiving object, setting the name to "Rose". After the slot function is executed, the code jumps to the position where the NewName signal is triggered, i.e. the "Emit this->newname (this->_p)" of the Click () method; "Back; the _p instance inside the Send Instance Name property is displayed at the end. It was observed that although the Name property was reset in the slot function, it did not change the attribute value of the signal initiator instance (still jack). So we can say that the signal of this transitive object is one-way communication with the slot mechanism. The direction of delivery is the signal sender to the receiver. Of course, this example is just a passing object, I experimented, if the above code to make minor changes, the transfer of parameters into the object pointer, it will eventually affect the data sent by the signal. As shown in the following:

That is, if you are passing pointers, the mechanism is two-way communication, and the key is to see how to use them. I personally do not recommend using pointer delivery. Because a signal can be bound to more than one slot function, if one of the data has been modified, it will affect the subsequent slot function execution, at this time the parameter state is unknown, is not easy to maintain. Of course, nothing is absolute, except under special circumstances.

Add another two points:

First: The term "slot function" mentioned above is not appropriate. Because the method cannot contain a return value. Must be void, so called "groove process" is more appropriate, but has widely accepted the term, so there is no drill down.

Second: At the beginning, for the sake of diagram, the definition and implementation of the three classes of Tperson, Tsender and Treceiver are put into main.cpp. The results are not compiled anyway. Tip "Undefined reference vTable for class ...", ... is the class name for these three classes. Later, it was found that when the QT program was compiled, the signal and slots definitions were invoked to convert the MOC tool into standard C + + code (signal and slots are not standard C + + keywords). The MOC tool only recognizes. h files, so be honest with the standard C + + class definition method, don't be lazy:)

http://blog.csdn.net/chaijunkun/article/details/6249573

Study on the transfer directionality of QT signal and slot mechanism (conclusion is wrong, but can look at the analysis process)