2

Is it valid to call qApp->exec() or QCoreApplication::exec() if I'm using a QApplication instance? Since it's a static function, in both cases QCoreApplication::exec() will be called. However, it appears that even if I call one of them, my QApplication based program works just fine - is this just luck/coincidence or is it ment to be valid?

Thanks for your help!

Felix
  • 6,885
  • 1
  • 29
  • 54

3 Answers3

1

Short answer:

It is not luck since static functions should behave like normal non-virtual functions also.

Long answer:

A static function is a member function that does not use this pointer. When you are calling it from an object it behaves like a normal member.

Since QAppliction is derived from QCoreApplication and exec() is a member of QCoreApplication, it is also a member of objects of types derived from QCoreApplication.

qApp returns a pointer to a QApplication object that is also a QCoreApplication so it also contans exec().

Dragos Pop
  • 428
  • 2
  • 8
  • qApp is not a function, so you can't call it like one (i.e. qApp() is an error). The object that qApp gives you is a QCoreApplication object, not a QApplication object. – Craig Scott Oct 24 '15 at 22:33
  • You are right, it is just a macro and using () is an error. Still, depanding on the type of application it is casted to the real type of the instance. For example, if you include QWidgets it will be casted to QApplication. – Dragos Pop Oct 24 '15 at 23:07
  • Ouch. So what qApp means depends on which headers you include. :( – Craig Scott Oct 24 '15 at 23:17
  • Thanks! Now I get it. For some reason I thought that `QApplication` has it's own `QApplication::exec` function, but it doesn't! That makes it clear. @Craig Scott: No, qApp always points to `QCoreApplication::instance()` – Felix Oct 25 '15 at 08:52
1

qApp is simply a #define to QCoreApplication::instance(). All qApp is doing in your usage of it is telling the compiler where to find the exec() function. But because exec() is a static function, it isn't being called through an object, even though your code makes it look like it is. So qApp->exec() should be entirely equivalent to QCoreApplication::exec() from the compiler's point of view. That said, I don't know if the C++ standard would require qApp to be non-null in this case, even though it technically doesn't need to be used.

Craig Scott
  • 9,238
  • 5
  • 56
  • 85
  • 1
    To be clear, as @dragos-pop mentioned, QApplication is just a subclass of QCoreApplication. In the original question, it makes no difference whether your application creates a QCoreApplication object or a QApplication object, you can still call exec() the same way. – Craig Scott Oct 24 '15 at 22:37
1

QT uses a singleton pattern on QApplication, so all your calls end up calling the single instance of QApplication. Why they chose to put qApp along for the ride is strange, but it seems the shortest string to type. I prefer keeping the pointer to the original QApplication which you created yourself.

Christopher Oezbek
  • 23,994
  • 6
  • 61
  • 85
  • I believe qApp is a historical hangover from the very early days of Qt. It may have begun its life as an actual global variable, but as my answer mentions, it is now just a #define for QCoreApplication::instance(). It has presumably been kept to allow older code to continue working with minimal code changes when people update to newer versions of Qt. – Craig Scott Oct 24 '15 at 22:26