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" <godbo...@amotus.ca>
> To: "interestqt-project.org" <interest@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-boun...@qt-project.org> On Behalf Of Giuseppe
> D'Angelo via Interest
> Sent: November 13, 2019 12:38 PM
> To: interest@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.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
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
