On 13/11/2019 18:11, Jason H wrote:
Maybe. Couldn't I just call: MySingleton::Instance()->MySignal();and skip emit altogether? I've read that Q_EMIT and emit are just syntactic sugar, and there is confusion in this stackexchange: https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-signal-as-if-its-a-regular-function-in-qt it seems that the simplest way is just: MySingleton::Instance()->MySignal(); but to make it clear it is emitting, the sugar comes into play. Not sure if it has any affect on queued vs direct-call connections though. (I'm guessing no)
"emit" / "Q_EMIT" are macros that expand to nothing.Therefore, after the preprocessor runs, the compiler does not see anything; whether emit was there or not makes no difference and thus results in no behavioral changes.
Still:1) use emit every time you emit a signal; emit is not there for the compiler, it's there for the developer
2) use emit ONLY in front a signal emission and nowhere else3) While signals are technically public members, I'd consider that an implementation detail; one should NEVER be emitting signals on behalf of another arbitrary class.
You should protect your signal emissions, e.g. use the same undocumented trick that Qt uses (make them have an argument of type QPrivateSignal), and give friendship to the only codepaths that are supposed to emit it (and, even better, have a trampoline function that emits the signal that these codepaths can call).
Clazy already checks for 1+2 and in theory can also check for 3. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
