-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add automatic FINAL detection to W_PROPERTY #40
Conversation
|
This is interresting. thanks for the patch. Can you add a test in tests/basic/tst_basic.cpp. You can add a final class and check its property are final. |
I wonder if it is this patch which cause this MSVC internal compilation error on AppVeyor. |
I don't think so, appveyor recently upgraded to VS 15.7 which does not work (#36) ; for my own projects I fixed by changing to |
This means we need to reimplement some Qt feature such as qOverload so it works also with MSVC Also this fixes MSVC compiling for x86 with Qt < 5.11 [woboq#30]
Testcase: template<typename T> struct MetaPropertyInfo { T t; constexpr auto setMember() const { return MetaPropertyInfo<T> {t}; } }; struct XX { static constexpr auto w_PropertyState() { MetaPropertyInfo<std::nullptr_t> meta{ }; return meta.setMember(); } }; int main() { constexpr auto doo = XX::w_PropertyState(); } woboq#36
Thanks again for the contribution. But thinking more about it, I am not sure this is a good thing anymore. The FINAL does not have so much impact on the code. It is only used on QML to throw an error if you override the property AFAIK. |
I think that this case cannot happen : since the C++ class is marked as final, it cannot be registered in the QML type system anyways since
which will not compile. Are there other cases ? Of course if it's only improving stuff in Qt Quick 1, it's relatively useless :p (the doc said |
So in summary, this patch is not so useful since:
Yet, the patch looks good to me and I will then merge it. |
(Merged) |
do you know if there is a reason for the current qml object registration mechanism to work like it does (by subclassing with an "empty" class?)
would there be some optimization opportunities in QtCore about this or not at all ? |
Actually, you can return any QObject* or Q_GADGET from a property, or give it in a QVariant. You can't extend the object like that, but we can access their properties. However, the final attribute does not help much.
I can't think of any optimization that this attribute would allow. |
I don't know if it's the correct way to do it (and what the exact effects of
FINAL
properties are, the doc doesn't really precises it) but in any case here it is