[Development] Rationalizing qApp and qGuiApp
elvstone at gmail.com
Sat Jan 18 13:32:59 CET 2020
Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh <szehowe.koh at gmail.com>:
> * The qApp macro changes type depending on which headers are included,
> and in what order. (If you #include <QGuiApplication> but instantiate
> a QCoreApplication, qApp returns a QGuiApplication pointer)
> * The documentation says that the qApp macro is only valid if a
> QApplication was instantiated. 
> * The qGuiApp macro doesn't change types like qApp; it is always a
> QGuiApplication pointer.
> * There is no equivalent of qGuiApp for QCoreApplication and QApplication.
> To resolve this inconsistency, I propose that we do one of the
> following for Qt 6:
> A) Update the documentation to say that qApp can change types. Leave
> the qApp macro as-is.
> B) Leave the documentation as-is. Make the qApp macro disappear from
> qcoreapplication.h and qguiapplication.h unless compatibility mode is
> C) Rename "QApplication" -> "QWidgetApplication", keeping the former
> as a typedef. Leave the qApp macro as-is but deprecated. Add the
> qCoreApp and qWidgetApp macros (analogous to qGuiApp)
How about deprecating the q*App variables altogether, and recommend
using e.g. QCoreApplication::, QGuiApplication:: et.c. instead? Static
analysis will warn when calling static functions through an instance
Though now I realize there are also non-static functions on these
classes, so probably not reasonable to do that *facepalm*.
As a user I think your suggestion sounds good.
>  https://codereview.qt-project.org/c/qt/qtbase/+/174414
> Development mailing list
> Development at qt-project.org
More information about the Development