[Interest] Most simple emit from singleton?

Jason H jhihn at gmx.com
Thu Nov 14 06:56:46 CET 2019


Yeah, it's a global event. Like tracking volume key events on a phone. ;-) I guess anyone can trigger them but the platform is invoking them in the handler. And my app is not considered to be hostile to itself. 

> Sent: Wednesday, November 13, 2019 at 11:18 PM
> From: "Jérôme Godbout" <godboutj at amotus.ca>
> To: "interestqt-project.org" <interest at qt-project.org>
> Subject: Re: [Interest] Most simple emit from singleton?
>
> 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
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


More information about the Interest mailing list