QCoreApplication::aboutToQuit is not a signal
-
@SPlatten
Agreed, but why did you just update Qt Creator?? For precisely this reason, why don't you stick with a stable version of Qt Creator/Qt version and stick with them for a quite a while? If you want to update every time there is a new, latest version, this sort of thing happens.... -
@SPlatten
:) As you please, just saying this leads to these probs! Anyway, either it's a bug inclazy
, or delete everything in the build output folder, in case there are "hidden"/other files left lying around after "build clean", which is what I do when I don't think an error is mine, and certainly after installing/upgrading anything. -
@SPlatten So I had the same issue where clazy would faulty flag
timeout
from QTimer as not a signal, which is of course nonsense.But it somehow went away, and I'm not sure what caused it.
Try one or both of the following:
- Change the kit, it should force a revelation of your code
- Close the project, delete the *.pro.user file, and open it again
-
Got the same issue with latest Qt Creator on MacOS (with iOS as project target). Clazy constantly complains about emitting and connecting non-signals - both in my own code as well as with signals from Qt classes like QTimer::timeout and so on. Full clean, rebuild from scratch and so on doesn't help.
-
I'm experiencing this as well.
Could it be related to the updated version of clang included with Xcode 12? In addition to updating Qt Creator recently, I also updated Xcode on my machine (macOS 10.15).
Looks like Qt Creator distributes its own version of clang. I'm assuming this is what the mac kits are supposed to use by default?
-
@evan_y said in QCoreApplication::aboutToQuit is not a signal:
Looks like Qt Creator distributes its own version of clang. I'm assuming this is what the mac kits are supposed to use by default?
No, that clang version is for the tooling provided by Qt Creator. Qt is not built with it, only the official Apple released Xcode clang is supported.
-
I've also observed other odd clazy messages:
QString strKey = QString("%1%2").arg(clsJSON::mscszAck).arg(clsJSON::mscszCmdHB);
Results in:
Use multi-arg instead [clazy-qstring-arg]
This is clearly rubbish, because the other arguments in .arg are for formatting the same argument and what I have done works perfectly. I've submitted another bug for this tonight.
-
@SPlatten What are the types of those clsJSON::mscszAck and clsJSON::mscszCmdHB? If they are both strings, this clazy warning is probably correct because there are overloads with multiple string arguments:
https://doc.qt.io/qt-5/qstring.html#arg-14
Your code should work perfectly as well, but it may be suboptimal.
-
You should read the documentation of the suggested arg overload before opening a report.
-
@KoneTaH they are static const char*, the prefix:
m = member
s = static
c = const
sz = null terminated stringclsJSON is the name of the class they belong to. I tried using the multi-arg version, its just not right. As I said, regardless of the message the code works and does exactly what I intended.
-
@SPlatten
If you want to know why you are getting this warning, I suggest that https://www.kdab.com/uncovering-32-qt-best-practices-compile-time-clazy/, 29. qstring-arg, is giving you the answer:Detects chained
QString::arg()
calls which should be replaced by the multi-arg overload to save memory allocations.QString("%1 %2").arg(a).arg(b); // Bad QString("%1 %2").arg(a, b); // one less temporary heap allocation
As @KoneTaH noted
Your code should work perfectly as well, but it may be suboptimal.