[delta_p_delta_x]

> A truly zero-cost abstraction

Sadly the MSVC ABI makes std::span and std::string_view a pessimisation:

https://github.com/tringi/win64_abi_call_overhead_benchmark

https://godbolt.org/z/7baaox7re

[usrnm]

Sounds like a compiler bug to me. It is a valid reason to avoid them in some rare cases right now, but it doesn't make the feature itself bad

[j16sdiz]

Those are ABI. Unless it is inlining them, the overhead is to stay.

[usrnm]

ABI changes do happen. gcc had an ABI change in std::string because of C++11. It was long and painful, but everyone survived, the world did not end

[delta_p_delta_x]

> ABI changes do happen

Will never happen on Windows, especially not in user-mode libraries, and especially not something this pervasive.

[pjmlp]

Contrary to the FOSS compile from source culture, other platforms have a different point of view on ABI breaks.

Which is why Valve ended up using Proton.

[gpderetta]

I'm pretty sure GCC has been ABI stable far longer that MSVC which used to break ABI every release.

GCC was forced to break the std::string ABI by the C++11 standard and they have been lobbing ever since against ABI breaks.

[wahern]

GCC/libstdc++ just changed the ABI for std::variant: https://gcc.gnu.org/gcc-16/changes.html#libstdcxx

[pjmlp]

You haven't used Windows in a while I imagine.

MSVC has stabilised the ABI since VS 2015, we are on VS 2026 now.

Due to customer pressure to stop doing exactly that, to the point some ISO C and C++ stuff that requires breaking the ABI has not been implemented thus far.

I am quite certain that I will find ABI breaks in GCC release notes since Slackware 2.0, when I used it for the first time.