Quite a frequent problem when working with signals with slots in Qt5, according to my observations on the forum, is the connection of slots in the syntax on the pointers to signals having an overload of the signature. The same applies to slots that have an overload.
Let's take a test class that has overloaded signals.
#include <QObject> class TestClass : public QObject { Q_OBJECT public: explicit TestClass(QObject *parent = nullptr); signals: void testSignal(int arg1); void testSignal(int arg1, int arg2); };
Here there is a signal, with an overload of the signature. Connect this signal will also be to the slots that are declared in the Widget class, and which also have an overload of the signature.
#include <QWidget> #include "testclass.h" namespace Ui { class Widget; } class Widget : public QWidget { Q_OBJECT public: explicit Widget(QWidget *parent = 0); ~Widget(); private slots: void onTestSlot(int arg1); void onTestSlot(int arg1, int arg2); private: Ui::Widget *ui; TestClass* m_testClass; };
How it was in Qt4
Within Qt4, everything was solved quite simply by specifying the signature of the signal and the slot in the SIGNAL and SLOT macros.
connect(m_testClass, SIGNAL(testSignal(int,int)), this, SLOT(onTestSlot(int,int))); connect(m_testClass, SIGNAL(testSignal(int)), this, SLOT(onTestSlot(int)));
How it became in Qt5
But in Qt5, when writing in the new syntax of signals and slots, there are some problems. Because you need to make the static_cast of the method signature.
connect(m_testClass, static_cast<void(TestClass::*)(int)>(&TestClass::testSignal), this, static_cast<void(Widget::*)(int)>(&Widget::onTestSlot)); connect(m_testClass, static_cast<void(TestClass::*)(int, int)>(&TestClass::testSignal), this, static_cast<void(Widget::*)(int, int)>(&Widget::onTestSlot));
By the way, the new syntax also allows you to connect signals to slots with a smaller signature, as it was in Qt4.
connect(m_testClass, static_cast<void(TestClass::*)(int, int)>(&TestClass::testSignal), this, static_cast<void(Widget::*)(int)>(&Widget::onTestSlot));
Advantages of the new syntax
And now a stumbling block. Why use the new syntax of signals and slots? I still hear this question from time to time. Especially when people see such terrible castes of signatures.
- Therefore, I will list potential advantages:The ability to track errors in the connection of signals and slots at the compilation stage, rather than in the runtime
- Reducing compilation time by excluding macros from the code
- The ability to connect lambda functions, it's quite an important bun
- We protect ourselves from errors when we try to connect from the outside to a private slot. Yes!! Yes!! The SIGNAL and SLOT macros ignore the access levels of methods, violating OOP.
In general, for me this is enough, but for you?
Отличная необходимая статья.