[Development] Deprecation/removal model going into Qt 6
thiago.macieira at intel.com
Mon Jun 3 07:58:36 CEST 2019
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 : 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
> > 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
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
More information about the Development