10

The common explanation for not fixing some issues with C++ is that it would break the ABI and require recompilation, but on the other hand I encounter statements like this:

Honestly, this is true for pretty much all C++ non-POD types, not just exceptions. It is possible to use C++ objects across library boundaries but generally only so long as all of the code is compiled and linked using the same tools and standard libraries. This is why, for example, there are boost binaries for all of the major versions of MSVC.

(from this SO answer)

So does C++ have a stable ABI or not?

If it does, can I mix and match executables and libraries compiled with different toolsets on the same platform (for example VC++ and GCC on Windows)? And if it does not, is there any way to do that?

And more importantly, if there is no stable ABI in C++, why are people so concerned about breaking it?

Alex O
  • 1,429
  • 2
  • 13
  • 20
  • 7
    *So does C++ have a stable ABI or not?* Nope. It's implementation defined. – NathanOliver Jun 04 '21 at 14:30
  • 1
    Jason Turner's [video](https://www.youtube.com/watch?v=By7b19YIv8Q) explains things pretty well. – 0x5453 Jun 04 '21 at 14:30
  • 1
    ***If it does, can I mix and match executables and libraries compiled with different toolsets on the same platform (for example VC++ and GCC on Windows)?*** It does not and this is UB. The msvc compiler in Visual Studio 2015 to 2019 are binary compatible but not compatible to mingw or any other version of Visual Studio when c++ code is involved. There is some compatibility with `c` only code. – drescherjm Jun 04 '21 at 14:31
  • There is no good reason for not having a standard abi and sadly I don't see any serious work spent on this topic. I don't believe that the C++ modules will ease assembly management noticeably, without an ABI standard, – Abdurrahim Jun 04 '21 at 14:47
  • 3
    There is sort of one - _Itanium C++ ABI_ - https://itanium-cxx-abi.github.io/cxx-abi/abi.html – Richard Critten Jun 04 '21 at 15:17
  • 1
    " This is why, for example, there are boost binaries for all of the major versions of MSVC." -> This has to be done BECAUSE there is no stable ABI. – Mooing Duck Jun 04 '21 at 22:43

2 Answers2

13

Although the C++ Standard doesn't prescribe any ABI, some actual implementations try hard to preserve ABI compatibility between versions of the toolchain. E.g. with GCC 4.x, it was possible to use a library linked against an older version of libstdc++, from a program that's compiled by a newer toolchain with a newer libstdc++. The older versions of the symbols expected by the library are provided by the newer libstdc++.so, and layouts of the classes defined in the C++ Standard Library are the same.

But when C++11 introduced the new requirements to std::string and std::list, these couldn't be implemented in libstdc++ without changing the layout of these classes. This means that, if you don't use the _GLIBCXX_USE_CXX11_ABI=0 kludge with GCC 5 and higher, you can't pass e.g. std::string objects between a GCC4-compiled library and a GCC5-compiled program. So the ABI was broken.

Some C++ implementations don't try that hard to have compatible ABI: e.g. MSVC++ doesn't provide such compatibility between major compiler releases (see this question), so one has to provide different versions of library to use with different versions of MSVC++.

So, in general, you can't mix and match libraries and executables compiled with different versions even of the same toolchain.

Ruslan
  • 18,162
  • 8
  • 67
  • 136
  • To be clear, as std::string is the default string class in C++, they broke compatibility with older C++ versions. This was the time to remove all old/bad/deprecated stuff from the language & std (imho). – jaques-sam Jun 08 '22 at 09:43
  • Note that MSVC has had ABI compatibility since 2015 (the linked answer is from 2009). – Błażej Czapp Apr 03 '23 at 19:30
0

C++ does not have an ABI standard as of yet. They are attempts to have it in the standard; You can read following it explains it in details:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf

NathanOliver
  • 171,901
  • 28
  • 288
  • 402
Abdurrahim
  • 2,078
  • 1
  • 17
  • 23
  • My understanding of that paper's position is that there **is** a _de facto_ ABI standard, that there has been since C++11, and that any changes to the C++ standard that would break ABI are routinely vetoed by implementers. – Tim Randall Jun 04 '21 at 15:15
  • Well it is a defacto standard. It does not define how assemblies/modules to be used. Otherwise we would have a standard about using lets say C++XY abi, from lets say C++23. We have such layers well defined for C for example (extern "C") why not have a (extern "C++XY"). This example is not good, but there needs to be something like that, maybe a compile/linker option, – Abdurrahim Jun 04 '21 at 15:25