The Not-So-Hidden Corners of C++ ABI Stability

The ISO C++ Committee has traditionally aimed for ABI stability in C++, which was recently reaffirmed as an explicit design principle after years of arguments both for and against.

Past ABI incompatibilities remain in the collective memory of C++ developers, such as the C++11 libstdc++ update and the frequent Visual C++ ABI breaks prior to the release of Visual Studio 2015. This past experience shows us how sensitive the ecosystem is to ABI updates—in ways that affect not only C++ developers but other ecosystems as well, most notably Python.

This talk provides an overview of past ABI breaks while challenging the assumption that a future, explicit ABI break would be equally problematic.

On the one hand, it may be argued that we haven’t had a significant disruption for about a decade, since both the C++ standard and compiler vendors have been very careful to avoid ABI breaks. On the other hand, ABI breaks or link incompatibilities never really went away. While the C++ standard makes significant efforts to keep the Standard Library ABI-compatible, the same cannot always be said for other commonly used libraries, resulting in problems either way.

Tooling has evolved significantly to meet the needs of developers in this area. For example, both Conan and vcpkg are able to “tag” different sets of binaries built from the same sources based on some arbitrary notion of compatibility. This even affects other ecosystems; more recently, there have been proposals in Python (such as PEP 817) to support concepts that address the same underlying problem of ABI incompatibilities.

This talk is not intended to argue about the merits or risks of future ABI changes, but to ask: Are we overestimating the pain of a future ABI break? Is it possible that tooling and changing practices have made us more comfortable coexisting with ABI incompatibilities?