Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh <szehowe....@gmail.com>: > > Currently, > > * 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. [1] > * 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 > enabled. > > 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) > > Thoughts?
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 anyway [1]. 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. Elvis [1] https://clang.llvm.org/extra/clang-tidy/checks/readability-static-accessed-through-instance.html > > > Regards, > Sze-Howe > > [1] https://codereview.qt-project.org/c/qt/qtbase/+/174414 > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development