The task: Currently, when using QMetaMethod::parameterType, we end up doing a costly string comparison. In order to get rid of the property cache in QML, we need faster way to obtain the metatype of method parameters and return types. This also has some benefits outside of QML, as it should speed up non-pointer-to-member function based connects, as well as QMetaMethod::invoke.
The first solution: Thanks to Olivier's work, we already have a way to create the QMetaType [1] for properties at compile time. The straightforward solution was to extend this work to also cover the QMetaMethod use case, which is what the patch at https://codereview.qt-project.org/c/qt/qtbase/+/294774 does. The catch: Unfortunately, in order to create the necessary information, we use templates. And those templates require the type for which we create the QMetaType to be complete (and if the type is T& or T*, T must be complete). While this mostly works for properties (as those often are backed by a member), for methods those types are often only forward declared. Getting qtbase to work with this was possible, but required larger changes (https://codereview.qt-project.org/c/qt/qtbase/+/297108, in addition to the fixes already in the initial patch). In many cases, that meant using Q_MOC_INCLUDE to tell the moc to include the necessary header.[2] More annoyingly, if a type is forward declared in a header and only implemented in a cpp file, the only way to get this to work is to include the moc file in the same cpp file. While doing this inside of Qt is possible, this is not something we can subject our users to. The proposed solution: In order to not break all the existing code, I would propose the following: We generate the QMetaTypes at compile time if possible. If the type is however incomplete, we store QMetaType::Unknown, and, at runtime, fall back to the slower string check to get the actual metatype. This is implemented in https://codereview.qt-project.org/c/qt/qtbase/+/298231. For classes exported to QML, we would then either generate a warning or an error if they lack complete types. We might also want a build system option to enforce having complete types. I would appreciate any suggestions, questions or complaints about the proposed plan. [1] Strictly speaking, the QMetaTypeInterface, which QMetaType then wraps. [2] Using a regular include works too, most of the time. It can however negatively affect compile times and breaks completely in the case of circular dependencies. -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
