[Development] Metatype system in Qt6

Olivier Goffart olivier at woboq.com
Mon Dec 9 10:04:13 CET 2019


On 05.12.19 21:19, d3fault wrote:
> On 12/5/19, Olivier Goffart <olivier at woboq.com> wrote:
>> That will not be working anymore if the MyType is only worward declared.
>> The user will have to do one of these:
>>    1. #include "MyType.h"  in the header
>>    2. Q_DECLARE_OPAQUE_POINTER(MyType *)
>>    3. Q_MOC_INCLUDE("MyType.h") : that's not yet implemented but would make
>> moc
>> include the file in the generated file.
>>
> 
>>
>> Now another question is what exactly do we want to automatically register.
>> Of course, we will register the way to construct, copy, and destruct the
>> types.
>> Now, should we also register automatically the other things that we can do:
>>
>>    - operator==
>>    - QDataStream operators
>>    - QDebug operator
>>
>> Ideally we also want this to be automatic, but i've run into an issue.
>> I naively tought it would be simple enough to just use SFINAE to detect if
>> the
>> type has the operator==, with something like that.
>>
> 
> 
> If qt6-moc depends on libclang [0], we could intelligently determine
> that MyType* is only forward declared and then transparently generate
> the required calls to Q_DECLARE_OPAQUE_POINTER(MyType*) where needed.
> Same goes for detecting ==operator/QDataStream/QDebug. I've heard
> Thiago say that depending on libclang is a no go [1]. Is this no
> longer the case for Qt6? Having libclang available during the
> precompile stages would open up a world of possibilities for Qt.

That's right, if we used clang we could be better at knowing if a type is 
defined or not. But even then that would be strange that you cannot invoke a 
slot from qml if its argument where not defined...
It would certainly help to detect if operator== is valid (although this would 
still be challeging: you'd need to inject some more code and see if it 
compiles, which also means you wouldn't be able to skip the parsing of function 
bodies.) This option could be considered once we port to clang. But that does 
not solve the general case.


More information about the Development mailing list