On Sunday, 2 June 2019 15:29:11 PDT Manuel Bergler wrote: > > Repeat after me: inline namespaces are not a tool to retain ABI. > > Of course they are. That's the reason they were introduced [0]: To > allow symbol versioning as part of the language without having to > write linker scripts, thus enabling standard library vendors to ship > both C++98 and C++11 conforming versions of the standard library types > in the same binary.
Except that this is inaccurate and just plain wrong. I don't care what the intention of the authors of the feature was, it's not to be used for keeping ABI. > > They may allow the library to provide both ABIs. That only makes the > > breakage move to the next library that uses those classes. > > The use itself is not the problem, only using them in public > interfaces will cause problems. But in that case inline namespaces > also allow users that are not able to update such a library to > explicitly request the old version by fully qualifying the type (e.g. > ::v61::QString instead of just QString). It would also be possible to In other words, a *non-inline* namespace? > create a feature toggle macro similar to libstdc++'s > _GLIBCXX_USE_CXX11_ABI to automatically switch which namespace becomes > the default one, but I'd not do that as this will incentivize users > not to update to the newer version. Thank you for using as example the last C++ change that caused Linux distributions to recompile EVERYTHING C++ (except the Qt libraries) because it broke compatibility. I don't know why libstdc++ folks bothered with the ABI tag. Everything needed a rebuild, so they may as well have just changed the soname. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
