Reviving old thread because it was discussed on IRC: On Friday 08 June 2012 10:31:31 Jedrzej Nowacki wrote: > 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.
What's wrong by saying that when there are "binary incompatible" registration, we keep the maximum of flag set? So the second registration which say the type is a PointerToGObject override the previous one. The code that expect PointerToGObject to be set for a given type will continue to work because that library should register that type. > 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. -- Olivier Woboq - Qt services and support - http://woboq.com _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
