SIGNAL/SLOT() macros in Qt's source code
-
Qt can do it correct but there are a lot of corner cases inside Qt which are hard to find out and there is a lack of manpower to change it. Also there is no reason to change it as it works.
-
Fair enough to @Axel-Spoerl & @Christian-Ehrlicher's answers.
One minor irritation for me, as an online code browser (don't know if this also arises if you have source inside your IDE code model, but I suspect it does). I was trying to find where all the calls are in Qt source to QTableView::columnCountChanged(). Since it's a
protected slotI know Qt source must call it. But the "helper" in code browser which allows you to see/go to all calls to a function, which I use a lot, was showing it only had 1 definition in.cppand 1 declaration in.h, i.e. not used anywhere. I had to do a bit of searching to discover https://codebrowser.dev/qt6/qtbase/src/widgets/itemviews/qtableview.cpp.html#1371connect(d->horizontalHeader, SIGNAL(sectionCountChanged(int,int)), this, SLOT(columnCountChanged(int,int)));since that does not show up as a call to
sectionCountChanged()because of the macro-to-string, where a PMF connection would have allowed the code browser to spot it. -
I fully agree with you, that macro based connections should all be removed.
@Christian-Ehrlicher has submitted cleanups, and should you find it tempting to submit patches - we'd be grateful.
I also clean them up whenever I find the time for it. Unfortunately there are other priorities, too. For all of us. -
Note that SIGNAL/SLOT syntax can also be used to add virtual dispatch to a function while not changing the binary compatibility of a class.
Like https://doc.qt.io/qt-5/qnetworkaccessmanager.html#supportedSchemesImplementation that was added as a protected slot in Qt 5.2 because adding a virtual method was not possible until Qt 6. -
Note that SIGNAL/SLOT syntax can also be used to add virtual dispatch to a function while not changing the binary compatibility of a class.
Like https://doc.qt.io/qt-5/qnetworkaccessmanager.html#supportedSchemesImplementation that was added as a protected slot in Qt 5.2 because adding a virtual method was not possible until Qt 6. -
If you see the old signal/slot syntax in official Qt examples let us know so we can remove them - they should no longer be advertised.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
J JonB has marked this topic as solved on
-
If you see the old signal/slot syntax in official Qt examples let us know so we can remove them - they should no longer be advertised.
@Christian-Ehrlicher AFAIK, I took care of that except in some places where it was really not possible.
-
@GrecKo
Yes, I knew there were some "advanced" reasons/cases where (apparently) one has to use old-style. I just wondered whether there was any good reason why, say, the example I came across needed to use it. It seems not.Hi @JonB ,
I was also asking this myself when I was browsing the Qt source for my topic here.
There you can also find interesting mentions made by @Christian-Ehrlicher and @SGaist .For example, I learned that the string-based and the PMF/Functor-based syntax are interchangeable in most cases, but not everywhere, as it is a widely spread myth :)
With both ways to connect you can do things the other way does not support. -
While it looks like something easy to change, disconnection during destruction is where it becomes tricky.
SIGNAL/SLOT based connections get disconnected, when either of the owning classes gets destroyed.
PMF connections stay alive, until theQObjectis eventually destroyed.
That can lead to crashes, if e.g. a signal is connected to&QLineEdit::setTextand the line edit has become a plainQObjectin the course of its destruction. When the signal is fired at this very moment, a dangling PMF would be called in a PMF based connection.
A macro-based connection would have been gone already, so the signal would be dancing on its own.That said, I have learned my lesson fixing old style connections as a drive-by. You need to wrap your head around it and make sure they either don't cause any grief - or get disconnected at the right time.
@Axel-Spoerl said in SIGNAL/SLOT() macros in Qt's source code:
While it looks like something easy to change, disconnection during destruction is where it becomes tricky.
SIGNAL/SLOT based connections get disconnected, when either of the owning classes gets destroyed.
PMF connections stay alive, until the QObject is eventually destroyed.
That can lead to crashes, if e.g. a signal is connected to &QLineEdit::setText and the line edit has become a plain QObject in the course of its destruction. When the signal is fired at this very moment, a dangling PMF would be called in a PMF based connection.
A macro-based connection would have been gone already, so the signal would be dancing on its own.I don't fully understand what you are saying here. I always thought that as long as you have a context object PMF and SIGNAL/SLOT would behave the same. Sure, lambdas cannot be disconnected automatically without a context object.
Where exactly is the problem? Does only SLOT enter the connection into a list of connected slots for the receiver and the PMF syntax does not do this? Is there a reason for this decision? Still, there must be some information saved to inform all potential senders at the point when the QObject base type is destructed.
@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:
With both ways to connect you can do things the other way does not support.
Can you point to some differences? I only can think about new things the PMF syntax supports, like connecting to functions not declared as slots (i.e. even member functions of class not derived from QObject) and connecting to lambdas. What are things you can to with the string-based syntax that is impossible with PMF?
-
IMHO, as a general rule, it's safe to use PMF syntax in applications.
The difference between "old" and "new" style kicks in when cascaded destruction takes place, and a signal is delivered to a stale object. In the Qt library, this happens (amongst others) to slots in private headers.You can have a look at https://codereview.qt-project.org/c/qt/qtbase/+/507788 for instance.
Just replacing string based connections with PMF syntax lead to crashes, when the model of a combo box would still emit signals to the box's private header when it was already destroyed.QMetaObjectdeals with this automatically, because it knows to which class the connection belongs. A PMF connection doesn't know when the slot object's d'tor is reached, so it needs to be explicitly disconnected. Otherwise a signal could be delivered toQComboBoxPrivatewhen it has already degraded to a plainQObjectPrivate.Software Engineer
The Qt Company, Oslo -
IMHO, as a general rule, it's safe to use PMF syntax in applications.
The difference between "old" and "new" style kicks in when cascaded destruction takes place, and a signal is delivered to a stale object. In the Qt library, this happens (amongst others) to slots in private headers.You can have a look at https://codereview.qt-project.org/c/qt/qtbase/+/507788 for instance.
Just replacing string based connections with PMF syntax lead to crashes, when the model of a combo box would still emit signals to the box's private header when it was already destroyed.QMetaObjectdeals with this automatically, because it knows to which class the connection belongs. A PMF connection doesn't know when the slot object's d'tor is reached, so it needs to be explicitly disconnected. Otherwise a signal could be delivered toQComboBoxPrivatewhen it has already degraded to a plainQObjectPrivate.@Axel-Spoerl said in SIGNAL/SLOT() macros in Qt's source code:
A PMF connection doesn't know when the slot object's d'tor is reached, so it needs to be explicitly disconnected.
Whaatt?! In user code (as opposed to whatever private inside Qt for its own purposes)?? I only use PMF, I have never had a problem, I am expecting it to deal with either signal or slot object being destroyed without my having to do anything. I suppose I may never have tested a slot object deletion, not sure...
-
Whaatt?!
I guess you will never experience any issue with PMF based connections, unless you start plumbing with private classes created next to your public ones, go for multiple inheritance cascades and complex destruction with signals emitted to private headers.
I don't want to create any panic, I am just answering the question why we don't simply remove all string based connections in our code. -
@Axel-Spoerl said in SIGNAL/SLOT() macros in Qt's source code:
While it looks like something easy to change, disconnection during destruction is where it becomes tricky.
SIGNAL/SLOT based connections get disconnected, when either of the owning classes gets destroyed.
PMF connections stay alive, until the QObject is eventually destroyed.
That can lead to crashes, if e.g. a signal is connected to &QLineEdit::setText and the line edit has become a plain QObject in the course of its destruction. When the signal is fired at this very moment, a dangling PMF would be called in a PMF based connection.
A macro-based connection would have been gone already, so the signal would be dancing on its own.I don't fully understand what you are saying here. I always thought that as long as you have a context object PMF and SIGNAL/SLOT would behave the same. Sure, lambdas cannot be disconnected automatically without a context object.
Where exactly is the problem? Does only SLOT enter the connection into a list of connected slots for the receiver and the PMF syntax does not do this? Is there a reason for this decision? Still, there must be some information saved to inform all potential senders at the point when the QObject base type is destructed.
@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:
With both ways to connect you can do things the other way does not support.
Can you point to some differences? I only can think about new things the PMF syntax supports, like connecting to functions not declared as slots (i.e. even member functions of class not derived from QObject) and connecting to lambdas. What are things you can to with the string-based syntax that is impossible with PMF?
@SimonSchroeder said in SIGNAL/SLOT() macros in Qt's source code:
What are things you can to with the string-based syntax that is impossible with PMF?
What @Christian-Ehrlicher said here
and here
That's (one of ) the reason(s) why the String-based syntax is still used with Qt's pImpl implementation and for "private slots".
AFAIK the PMF can connect to non slot-declared functions, but only within QObject-derived classes.
The string-based connection does not need QObject receiver.
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@SimonSchroeder said in SIGNAL/SLOT() macros in Qt's source code:
What are things you can to with the string-based syntax that is impossible with PMF?
What @Christian-Ehrlicher said here
and here
That's (one of ) the reason(s) why the String-based syntax is still used with Qt's pImpl implementation and for "private slots".
AFAIK the PMF can connect to non slot-declared functions, but only within QObject-derived classes.
The string-based connection does not need QObject receiver.@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:
The string-based connection does not need QObject receiver.
The signature is
QObject::connect(const QObject *, const char *, const QObject *, const char *, Qt::ConnectionType )though -
@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:
The string-based connection does not need QObject receiver.
The signature is
QObject::connect(const QObject *, const char *, const QObject *, const char *, Qt::ConnectionType )though@GrecKo said in SIGNAL/SLOT() macros in Qt's source code:
@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:
The string-based connection does not need QObject receiver.
The signature is
QObject::connect(const QObject *, const char *, const QObject *, const char *, Qt::ConnectionType )thoughThis was referring to this overload:
QMetaObject::Connection QObject::connect(const QObject *sender, const char *signal, const char *method, Qt::ConnectionType type = Qt::AutoConnection) constWhich implies that the target is the current object.
This is different from the similar (yet different) PMF variant as there's no implicit target in that case. Hence the recommendation to use the variant which has a context object.
