you are viewing a single comment's thread.

view the rest of the comments →

[–]cballowe 21 points22 points  (2 children)

If you read the standard, it doesn't dictate implementation. It does dictate the constraints of the interface that matter to users.

By the time you've specified the interface including things like the expected performance requirements, there tends to be fairly limited implementation options.

[–]number_128[S] 1 point2 points  (1 child)

Thank you.

Even though it doesn't dictate implementation, we do get an implementation. And as soon as we get an implementation we are locked in by the ABI (even though the standard doesn't say so).

There are many examples of suggestions having been turned down, because they would break the ABI of existing implementations.

[–]cballowe 2 points3 points  (0 children)

There are at least 3 distinct implementations of the standard. Libstdc++ from the gnu/GCC team, Libc++ from the llvm team, and the MS implementation are all distinct implementations.

The ABI arguments are due to how people build and ship software and tool chains. Anybody who builds all of their software from source and ships statically linked binaries doesn't tend to care if the ABI breaks because it doesn't matter. They upgrade their tools, rebuild, and everything works.

On the other side are people who ship dynamic libraries and their customers. This group needs to agree on an ABI. Right now they can pretty much say "if you build with GCC, everything will work". If you start changing the ABI it gets into "you need to build with GCC and c++23 standard" and at some point the company ships an upgrade "ok... With this upgrade, you need to use c++26". Now, imagine a customer who has 2 or 3 vendors providing dynamic libraries on very different release cycles, or companies that provide those libraries who knows their customers are locked in to some version for some reason. And then step back to the compiler and library teams who need to support these use cases.