On terça-feira, 23 de abril de 2013 19.47.25, Olivier Goffart wrote: > On Tuesday 23 April 2013 08:48:41 Thiago Macieira wrote: > > I'm going to wait for other people to suggest solutions to this. Mine, for > > the moment, is a hammer... > > My suggested solution: > > In the header: > Put those functions in an inline namespace. (Or a normal namespace followed > by an using declaration).
Thank you! That's why I wanted someone to provide a solution. Yours is definitely much simpler and helpful than what I had in mind. > In one translation unit, keep an exported version of the old symbols which > calls the new symbol in the namespace, to keep binary compatibility. Right, that falls under the "de-inlining a function" category of binary compatibility. We keep the source compatibility by using an inline namespace. It's highly unlikely that anyone will #include both modules in the same translation unit. > That way, the problem is solved if the application is compiled against Qt > 5.1 or later. > If the application or one linked library is compiled against QtQml or > QtDeclarative from 5.0, and that this library uses one of the problematic > symbol, the crash can still happen. So one must still not link both QtQml, > QtDeclarative, and an old library together. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
