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 <[email protected]> | 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
