On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > > versioning. It allows to make that totally transparent. Why you find > > > > > that so odd as to be lacking for words is beyond me. > > > > > > > > Inline namespaces do not solve the binary compatibility problem. They > > > > should not be used in Qt API for versioning. > > > > > > > > Instead, do what you said before: create a V2 class. > > > > > > Since the two are totally identical, except that inline namespaces are > > > transparent to the user, please explain what leads you to this > > > distinction. > > > > Library 1: > > inline namespace v1 { class Foo {}; } > > > > Library 2: > > LIBRARY2_EXPORT void registerPlugin(Foo*); > > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > > > Application: > > registerPlugin(new Foo); > > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > > When Library 1 puts Foo in the v2 inline namespace, recompile Library2 > > and > > the exported symbol becomes "registerPlugin(v2::Foo*)". If Application is > > not recompiled, it will not work as the old symbol is no longer found. > > Well, of couse. That's like removing the QFoo overload when you add QFooV2. > Don't do that. You need to keep the v1::Foo definition as well as the > v1::Foo overload, just as you need to keep the QFoo definition and the QFoo > overload, when you add v2.
What I meant is that Library 1 becomes, in its next version namespace v1 { class Foo{}; } inline namespace v2 { class Foo{}; } It keeps v1::Foo, but puts v2::Foo in the inline namespace. If you don't use "inline namespace v2", that means users needs to explicitly use v2::Foo to use the new features. So it is no longer "transparent to the user" Personally I prefer having a pimpl so I can just add or change members. (Note that if the class is at least sizeof(void*) and that none of its member are accessed in inline methods or ctors/dtor, we can add a pimpl later, when we need it.) > > So what that means is that technically, Library 1 did not break its binary > > compatibility. But any library using Library 1 in their ABI is breaking > > compatibility when they get recompiled. > > > > GCC's ABI tag extension have the exact same problem. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development