Hi, Qt meta-type system is assuming that type information is constant and consistent. It make sense because in C++ a type trait can not be changed during execution of an application. We agreed that unregistering of a type is a bad idea and that updating a type data can cause malfunction in Qt itself (not mentioning external library or applications). In Qt5 we introduced a lot of template based auto-detection for different features. Most of the data gathered by QTypeInfo, QMetaTypeId helpers classes are stored in QMetaType internal data, so it can also be used during a runtime introspection. So far so good, we have inlined data which is constant and consistent with data that we stored in QMetaType. So what will happen if we compile an application with an older Qt and link against a newer one, assuming that we introduced or changed a new type's information? Nothing special :-), during type registration old data will be registered, so again both source of type data would be consistent.
To break the current design a 3rd client of the type data has to be introduced. It can be Qt itself or a library linked with Qt. So lets create theoretical situation that we created a new type flag isPointerToGObject in Qt5.1. Then someone write an application that is compiled against Qt5.1 and use that flag with a type T that is coming from a 3rd party library compiled with Qt5.0. Now, if both, the application and the library register the same type T in Qt we will detect binary incompatible registration. It will be like that because the application will have different feature detection inlined code then the library. What can go wrong then? From nothing to crash, it depends on the flag. For example if the flag is just an optimization hint, like "typeHasThreadSafeConstructor" then it is quite safe because we could "downgrade" the registered data to a safe value, it would work, maybe a bit slower :-). On other hand isPointerToGObject doesn't have such safe value, because it points to a feature that is rather a type description. Currently we save "NeedsConstruction", "NeedsDestruction", "MovableType", "PointerToQObject", "IsEnumeration" flags. It would be great to save more in future, as it is really useful. Please mark that if there is a bug in code that detects the last two features, we will not be able to fix it until Qt6. What now? We can: 1. ignore the problem as an edge case, to be honest the scenario is quite complex. 2. create a policy to add only "downgradable" flags, so in case of problems we will fall-back to a safe value. 3. start versioning types data, always access a data information with a special implicit marker. 4. drop concept completely. I believe that only option 2 and 3 are acceptable, but I would love to know what you think. Cheers, Jędrek
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
