On 05.12.19 21:19, d3fault wrote:
On 12/5/19, Olivier Goffart <oliv...@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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
