Sorry for the late reply, I was really busy the last few days.
No need to get angry, you asked for an opinion, which is what I gave. Nobody said you must listen to my/our opinion.
@thierryhenry14 said in Using a single shared Object as a message bus in the entire application?:
Before Qt 5 we didn't even have compiler checks on connect() calls, didn't stop people from writing great Qt 4 apps.
I guess, but on that particular note before Qt5 signals were private (for the mentioned reasons). The fact that you can now emit a signal from outside the object is an implementation detail. Don't get me wrong, I've done it, it's sometimes useful if you have coupled objects (like a manager class that may need to force the emission through its underling), but it still is frowned upon.
Regarding DBus...
The DBus mention was just as an example, no one implied you should use it for objects communication. It wasn't designed for this, on the contrary it was conceived as an IPC layer.
b) I would need to constantly convert between C/C++ types and Qt types, write serialization/deserialization code, etc, which is a nightmare
Actually Qt has a DBus implementation, but that's really moot.
c) I would lose the automatic thread safety you get from Qt's AutoConnection (I know there's caveats, but for the most part it works great)
Again, you could simply pump messages through the event loop. I don't see how using a signal-slot call is somehow better or different.
This sounds horrible to me. I'm not seeing what I'm gaining by using "a real bus".
You gain (some) decoupling of the implementation from the data interface. Or to phrase it another way:
Why would unrelated components need to know what others implement, support, demand or represent. To give you an example, how does my radar control care about what data types are marshaled through and what interfaces are implemented by my data processing. Why would the radar component need to be recompiled (or possibly changed) to accommodate completely unrelated changes.
Regarding my QObject bus being singleton...what is your justification for saying this?
Just by merit of it coupling everything together. Everybody knows about it and it knows about everything.
The AppMessageBus in my example holds no state as you can see, it just has signals.
It doesn't hold its own state, it is a state for the whole application though. It basically does what QCoreApplication will have done - manage event dispatching. Btw, beside some initialization of unrelated (to this case) code, this is essentially the crux of the application object.
Also, having the technical ability to use QCoreApplication doesn't mean I should do it.
Of course, to reverse that argument though, having the technical ability to emit from outside a QObject doesn't necessarily mean that you should do it, right?
Btw, if you look at my example, it's not a global variable, I give it as a constructor argument to the components that need it.
So? That's simply an implementation detail. I create my singleton objects (whenever I need them) in main(), similarly to how QCoreApplication does it, but does that make them less global?
