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

[Olivier Goffart]

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