[Development] QQmlListProperty<T>: static_assert that T inherits QObject
Simon.Hausmann at qt.io
Fri Jan 27 16:49:15 CET 2017
Regarding the question about why the engine itself uses QQmlListProperty<void> internally when populating
list properties during instantiation, I think you've already found the answer yourself: Because of interface types :)
I think it would be great if incorrectly used types could be reported to the developer as early as possible, but at the same
time the ability to things like forward-declaring "Foo" used by "Q_PROPERTY(QQmlListProperty<Foo> ...)" is likely a feature
used by many people when designing class interfaces. So I'm not sure it's a good idea to suddenly break their build when
upgrading to a new version of Qt.
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Milian Wolff <milian.wolff at kdab.com>
Sent: Friday, January 27, 2017 12:20:46 AM
Subject: [Development] QQmlListProperty<T>: static_assert that T inherits QObject
the QQmlListProperty states:
"Note: QQmlListProperty can only be used for lists of QObject-derived object
Since I am bad at reading documentation, I previously tried (I think multiple
times) to do something like:
This happily compiles and only at runtime does it not work. So I thought I'd
add a static assert to QQmlListProperty to check this at compile time:
But this uncovered this gem inside qtdeclarative itself:
158: QQmlListProperty<void> _currentList;
Uhm, a void* list, really? Should this be a QQmlListProperty<QObject>?
Digging further, I find a few places where QQmlListProperty<T> is instantiated
for non-QObjects, mostly within qmlRegisterUncreateableType, which is easy to
prevent by leveraging std::enable_if.
Digging even further, I hit the first road-block though with my approach:
Adding the static assert directly to QQmlListProperty means that T must be
fully defined when the list property gets used. Does this make this change
source-incompatible? Is there a workaround for this? I fixed the issues inside
Qt Declarative itself, but I wonder whether this is acceptable for existing
users of QQmlListProperty outside of QtDeclarative.
The second road-block comes when compiling the tests - apparently
QQmlListProperty also works with interfaces! So I added another type trait for
that. Is that acceptable?
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
KDAB - The Qt Experts
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development