On sexta-feira, 8 de junho de 2012 10.31.31, Jedrzej Nowacki wrote: > 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?
That cannot happen. A type's information cannot change incompatibly from one
version to the next. It must stay constant until Qt 6. Take for example the
movability flag: if a type changes from unmovable to movable, QList's
allocation strategy might change.
A type's information can only be modified by adding new traits.
> 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.
Indeed. Type registration should happen in only one point -- that's a major
weakness of registrations.
But see what I said above: type information CANNOT change incompatibly. That
is also true for new flags: they cannot be automatic if they change
incompatibly and this type was used before.
> 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.
I'd suggest that any automatic flags can only exist if they are either:
a) present in Qt 5.0
b) completely forwards and backwards compatible for all uses (something that
might be hard to prove)
Any other flags must be user-specified, with Q_DECLARE_TYPEINFO. That way, we
guarantee that the flag will remain the same throughout the lifetime of Qt 5
and that type.
Changing any of the flags that can pose incompatible problems is a binary-
incompatible change of the type itself. It must not be done if the library
providing that type wishes to remain BC.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
