[Development] Rationalizing qApp and qGuiApp

[Elvis Stansvik]

Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh <szehowe.koh at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development