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

Stephen Kelly stephen.kelly at kdab.com
Fri Aug 31 19:37:17 CEST 2012


On Wednesday, August 29, 2012 17:22:39 Olivier Goffart wrote:
> On Wednesday 29 August 2012 16:55:31 Jedrzej Nowacki wrote:
> > On Wednesday 29. August 2012 14.46.17 ext Olivier Goffart wrote:
> > > Reviving old thread because it was discussed on IRC:
> > > 
> > > On Friday 08 June 2012 10:31:31 Jedrzej Nowacki wrote:
> > > > Hi,
> > > > 
> > > >   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.
> > 
> > Hi,
> > 
> > PointerToGObject is a boolean how would you say which value is supperior?
> > 
> > if (flags & PointerToGObject)
> > 
> >   storeDataInPointerContainer(object)
> > 
> > else
> > 
> >   storeDataInNormalContainer(object)
> > 
> > It means that the flag can change during execution of an application. I
> > would say no for such solution ;-).
> 
> I see... that would indeed be a problem.
> But if we are aware of it we can still make good use of PointerToGObject

I have to say, I don't see the problem.

Where does if (flags & PointerToGObject) appear? In Qt 5.1, right otherwise 
PointerToGObject would not be defined. The plugin compiled against Qt 5.0 
can't contain code like that. Whether the metatype is a pointer to gobject is 
simply irrelevant to the plugin, until the author of it decides it is useful 
and recompiles with a dependency on Qt 5.1.

I don't see the problem.

In a similar vein, 

https://codereview.qt-project.org/#change,34042 

would make metatype registration also record whether the metatype is a 
QList<T> or a QVector<T> (in 5.1). That is no different to any other Qt 
release which adds overloads of existing methods which carry newer parameters 
and therefore newer meanings.

Is it acceptable to do that for 5.1?

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120831/8fb844e7/attachment.sig>


More information about the Development mailing list