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

[Jedrzej Nowacki]

On Friday 8. June 2012 12.31.50 ext Thiago Macieira wrote:
> 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.

Keep in mind that by introducing a new trait you are actually changing 
existing state. Imagine that we do not have movable flag. So by default 
everything is not movable. Then we introduce it, suddenly some types virtually 
change movable attribute. In this case it 98% safe, because default value is 
always valid.

> (...)
> 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)

a) And bug-less... such flag can not be fixed without recompiling.
b) Such requirement makes the flag completely useless. I hope that you mean 
forward compatibility, which means that an app compiled with an older Qt 
version would work correctly with a newer Qt version.
 
> 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.

User-specified flags make sense, Thanks for feedback.

Cheers,
  Jędrek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120611/45b05f84/attachment.html>