What's the issue with abi stability? GCC broke the Library ABI with C++11 but the old ABI was still available. I thi k it still available in C++14 and 17 mode.

If you switched to the new ABI with c++11 then c++17 as far as I know brings no new breakages.

No, std::string definitely changed between c++11 and c++14. It could be an implementation detail between different libstdc++ versions for the g++ version that supported c++14, but the incompatibility was definitely there.

> No, std::string definitely changed between c++11 and c++14. It could be an implementation detail between different libstdc++ versions for the g++ version that supported c++14, but the incompatibility was definitely there.

that is a problem with your distribution (and the reason why using distro packages sucks for development), not with C++.

The ABI only changes if you change the value of _GLIBCXX_USE_CXX11_ABI with libstdc++

See : https://gcc.godbolt.org/z/QLbjjo

Your example breaks if you change the C++11 pane to GCC 4.9 or earlier, which is the default in CentOS 7 and Ubuntu 14.04.

Considering that was only 5 years ago, I wouldn't consider this a stable ABI.

but again you can revert to gcc-4.9 behaviour with -D_GLIBCXX_USE_CXX11_ABI=0

I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportunities to create more libraries.

ABIis hard because C++ structures are typically more complex than C structures. While the C documentation could simply include the struct (and the ABI would constrain padding, etc), consider a simple std::string, which may (OK, will) have small string optimization: different runtime libraries might make different tradeoffs as to how to do this. You'd have to constrain the entire standard library for your platform which could forestall improvements down the road. The committee already unwittingly made that mistake with std::map and doesn't want to make that mistake again.

C++ also insists on inlining code extensively across the provider/client boundary, so if the offset of any data element changes the binary library is no longer backwards compatible.

This is exacerbated by the lack of usability in compilation toolchains that promotes header-only libraries just for build simplicity and for which the data structures often won't be compatible across .so boundaries.

Not dissing your comment, just pointing out that the committee is not just aware of the problem but slowly doing what it can to address them. C++17 and C++20 have a bunch of features to improve both of these factors.

There are also a number of features not really intended for user code designed to help make libraries faster, and more stable. The downside of course is, well, just look at library source. But really the source to the C standard library has similar issues.

I don't like header-only libraries because they slow down compilation, and slowly the trend is starting to abate.

They do. ABI breaking changes are routinely voted down unless they are really worth it (and the only non backward compatible change that was accepted that I'm aware is the std string changes in C++11).

This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...

Thanks for the link, a good read.

As somebody who kicks C++'s tires once in a while and is always put off by the incredible complexity of the language, and the complexity and friction and fragility of its workflow, I was sad not to see any explicit mention of pairing an ABI break with removal of the bad parts. (Yeah, I know, that might mean source-level backwards incompatibility...) Makes me wonder if it's ever even discussed at a high level.

Maybe things are better now but in the past almost every new library I added to my projects required a lot of fiddling with headers , link options and other stuff. With C# this is so easy in comparison.

Sounds like a job for an llvm tool. The parse tree is exposed, doing the transform shouldn't be ridiculous? Are you keen enough?