[Development] Possible binary compatibility problem in a future Qt version

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120608/26e7fac4/attachment.sig>