[Development] Notes on Metaobject & QML discussion @ QCS2016
Olivier Goffart
olivier at woboq.com
Mon Sep 5 14:13:03 CEST 2016
On Samstag, 3. September 2016 15:03:05 CEST Thiago Macieira wrote:
> https://wiki.qt.io/QtCS2016_MetaObject
>
> * qMetaType<const T>() == qMetaType<T>()
> ** Because QMetaObject::normalizedType("const T") == "T"
> ** Fix it
QMetaObject::normalizedType("const T") -> "T" //OK
QMetaObject::normalizedType("T const") -> "T" //OK
QMetaObject::normalizedType("const T*") -> "const T*" //OK
QMetaObject::normalizedType("T const *") -> "const T*" //OK
QMetaObject::normalizedType("T* const") -> "T*const" // Wrong (const not
removed)
QMetaObject::normalizedType("const T* const") "T*const" // VERY WRONG!
QMetaObject::normalizedType("T const * const") -> "T*const" // VERY WRONG!
So QMetaTypeId2 can be adapted fixed so that qMetaType<const T>() ==
qMetaType<T>(). That should be a compatible change because normally const
type could not be register anyway.
QMetaObject::normalizedType should be ideally fixed as well. However this
might be a compatibility problem as their name might be encoded by moc.
Last time we change the normalization, we had to make sure to still understand
function from the old moc object. See commit
b881d8fb99972f1bd04ab4c84843cc8d43ddbeed (in Qt 4) (Similar bug fix)
> * Q_NAMESPACE
> ** Keep it in 5.8
> ** look into having it with multiple .h
> ** Q_ENUM_NS(OtherNamespace::Enum) or using Enum = OtherNamespace::Enum; is
> a good idea
> * Direct property access via the qt_static_metacall
Since Qt 5.5, the code that write the property is in qt_static_metacall rather
than in the virtual qt_metacall. QML could optimize by calling directly the
qt_static_metacall. However QML can't do it unconditionally otherwise it will
break with old objects, it needs to check the PropertyAccessInStaticMetaCall
flag. 4e9fc0129d6b4326c2159e4fafa42a3df9d35e0a in qtdeclarative need to be
fixed.
But moc does not set this flag by default because of the hack in qdbusxml2cpp.
> ** qdbusxml2cpp
> ** Add property & setProperty to QDBusAbstractInterfaceBase
Thiago, are you taking care of that?
> * Generated hash table
The goal is to be able to simplify or get rid of the current Qml's Property
hash table.
> ** properties, methods, enums
> ** hashing table needs to encode the type (Q_SIGNAL_CODE)
Not Q_SIGNAL_CODE, we would need a flag for what it is (method, property,
enum, ...) and maybe it's going to be a multi-hash.
> ** perfect hashing doesn't help
The way I see it, we increase the metaobject revision number, and we add
int hashTableSize, hashTableOffest in QMetaObjectPrivate.
We then generate a hash table.
This could be an open addressing hash table (The moc can be smart and order
the entries properly to reduce the clustering. Or use the "robin hood" scheme)
> ** check if we can encode the hashing of the entire hierarchy
> ** "prelink" the class to its parent, recursively, but check at runtime
If we encode the entire hierarchy, the hash become invalid if the base class
are upgraded because of a library upgrade that adds or reorder property. (even
if the common case is that there is no change)
One way to check for change would be to store in the QMetaObject's data a
QCryptoGraphicHash (to avoid collision) of all the properties, methods, ...
And also the one of the base class. So they can be compared at runtime.
We could also have a pointer from the QMetaObject to be a pointer to a read-
write location. It would point to something like:
struct QMetaObjectExtraData {
QAtomicInt initialized; // Set to 1 once we have done the runtime check
int *hashTable; // a pointer to the hash table. the one pre-generated,
// or another one on the heap if that was not valid.
int extraArray[]; // can contain the cache of the type ids
};
This actually does not need to be part of the QMetaObject itself, but can be
in a QHash<const QMetaObject *, QMetaObjectExtraData>
> * For Qt6:
> ** metatype vs C++ RTTI
> ** qMetaType<T>() == &typeid(T)
--
Olivier
Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
More information about the Development
mailing list