[Interest] Most simple emit from singleton?

Jérôme Godbout godboutj at amotus.ca
Wed Nov 13 23:18:08 CET 2019


Q_EMIT and emit macro are blank indeed.

I was under the impression, that this singleton was a global signal emiter where anybody could launch a signal

class SingletonClass : QObject
{
Q_OBJECT
public:
   void TriggerGlobalEvent() { myGlobalEvent(); }
signals:
   void myGlobalEvent();	
}

so anybody can connect to that particular event like it was some kind of event bus for a particular Thread only, since the SingletonClass is a QObject and it has his own thread affinity.  So calling the signal directly or from the public method won't change anything as long as the current thread is the right thread affinity. Maybe I'm wrong on this but I think the result will be the exact same when calling TriggerGlobalEvent() or myGlobalEvent() on the object into a release build, the odds are that it will get inlined pretty quickly by any decent compiler.

This sound like a bad design to me but could work for some application wide events or settings changed. Since we do not really know the real purpose, it's hard to have a better way.

-----Original Message-----
From: Interest <interest-bounces at qt-project.org> On Behalf Of Giuseppe D'Angelo via Interest
Sent: November 13, 2019 12:38 PM
To: interest at qt-project.org
Subject: Re: [Interest] Most simple emit from singleton?

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-s
> ignal-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 else

3) 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.dangelo at 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



More information about the Interest mailing list