[Interest] Is QEventPrivate a remnant?

[Thiago Macieira]

On quinta-feira, 11 de fevereiro de 2016 20:01:08 PST Nye wrote:
> Hello,
> It seems some elaboration is in order to explain why I've done that the way
> I did.

The only reason to subclass one of Qt's QXxxxPrivate classes is if you're 
developing something as part of Qt.

If you're feeling adventurous, you may want to access one of those classes, 
without deriving from them. But you're still accessing private API and you're 
subject to the "We mean it" comment in the header. Your binary will be tagged 
on Linux as "Qt5_PRIVATE_API" and Linux distros will give you a dirty look.

> I'm wrapping around the OpenMPI library for purposes of running the
> particular library with my applications on a cluster. What I'm trying to
> achieve is to have the MPI messages come as events through Qt's event
> delivery system in the "most natural" way possible. I don't intend do
> disable the sockets, nor the timers, provided by the default
> implementations of the event dispatchers, so for that purpose, I derive my
> event dispatcher either from QEventDispatcherWin32 or QEventDispatcherUNIX
> depending on the Q_OS_* macros. 

How do MPI messages come through normally? On a Unix system, there are only 
two possible sources of events: file descriptors and timers. On Windows, 
there's a third (HANDLE events, for which there's QWinEventNotifier).

Why couldn't you use one of those and build upon it?

> Then in the dispatcher's processEvents() I
> pull the MPI messages before calling the superclass' implementation of the
> aforementioned method. The platform specific event dispatchers are already
> a part of the private API, so when deriving from QCoreApplication I've
> taken the liberty to do the same for the private object, and to pass it
> through the appropriate constructor. Additionally, I'm calling
> the QCoreApplicationPrivate::eventDispatcher->startingUp(); and the
> corresponding QCoreApplicationPrivate::eventDispatcher->closingDown();
> functions as noted in the comments in the QCoreApplication source (and as
> done in QGuiApplication).

Yeah, you *can* do it. You just shouldn't.

Maybe what we need to do is discuss how to integrate OpenMPI better into Qt, 
so you don't have to have those hacks in the first place.

> I'm aware that I'm breaking binary compatibility, but since Qt and my
> library will be built on the cluster manually (it's not installed, and
> won't be at some point in the future) this doesn't seem to be such a
> problem. However, any suggestions on how I could've done better by my code
> are greatly appreciated!

You're not breaking binary compatibility because you didn't modify Qt. But you 
are subject to compatibility on symbols that don't guarantee it. The "We mean 
it" comment applies.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center