4 ms·

> C++ is performance first at any price. Hence UB. I don't think this is entirely correct, C++ in some cases famously preferred ABI compatibility over maximum

> C++ is performance first at any price. Hence UB. I don't think this is entirely correct, C++ in some cases famously preferred ABI compatibility over maximum performance.

vlovich123 4y ago
C++ has no ABI defined. Did you mean API comparability? Would help to clarify some examples
- sirwhinesalot 4y ago
  While the C++ standard does not define any ABI, some implementations (namely GCC and clang) put a lot of effort into maintaining reasonable ABI compatibility. GCC has only changed ABI twice (afaik) and the second time the only thing that changed was std::string! Nowadays MSVC tries to maintain ABI compatibility too, so we should stop seeing a proliferation of those msvcrXXX dlls. Haiku uses C++ for its OS ABI so it relies quite heavily on the fact that ABI compatibility stays very consistent across compiler versions for example.
  - pjmlp 4y ago
    Same applies to Rust, with the difference that there isn't a story for shipping binary libraries, that is why OSes like Haiku care about keeping the ABI consistent, those BeOS applications aren't going to be recompiled.
- bigbillheck 4y ago
  https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...
  - vlovich123 4y ago
    Instead of breaking ABI compat for `unordered_map` why not define a new type given that it's so different? It can even be called the same thing and just exposed through a different namespace version (something that's been supported for a while). About the only thing real is intmax_t. The rest feel resolvable within a library without changing ABI / breaking back compat.
- mort96 4y ago
  The committee won't change something if the change would break the ABI of one of the big implementations. It's not a formalised ABI stability promise, it's just a result of implementers having veto power and wanting to keep their implementation's ABI stable.

> C++ is performance first at any price. Hence UB. I don't think this is entirely correct, C++ in some cases famously preferred ABI compatibility over maximum performance.

vlovich123 4y ago

C++ has no ABI defined. Did you mean API comparability? Would help to clarify some examples

sirwhinesalot 4y ago
While the C++ standard does not define any ABI, some implementations (namely GCC and clang) put a lot of effort into maintaining reasonable ABI compatibility. GCC has only changed ABI twice (afaik) and the second time the only thing that changed was std::string! Nowadays MSVC tries to maintain ABI compatibility too, so we should stop seeing a proliferation of those msvcrXXX dlls. Haiku uses C++ for its OS ABI so it relies quite heavily on the fact that ABI compatibility stays very consistent across compiler versions for example.
- pjmlp 4y ago
  Same applies to Rust, with the difference that there isn't a story for shipping binary libraries, that is why OSes like Haiku care about keeping the ABI consistent, those BeOS applications aren't going to be recompiled.
bigbillheck 4y ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...
- vlovich123 4y ago
  Instead of breaking ABI compat for `unordered_map` why not define a new type given that it's so different? It can even be called the same thing and just exposed through a different namespace version (something that's been supported for a while). About the only thing real is intmax_t. The rest feel resolvable within a library without changing ABI / breaking back compat.
mort96 4y ago
The committee won't change something if the change would break the ABI of one of the big implementations. It's not a formalised ABI stability promise, it's just a result of implementers having veto power and wanting to keep their implementation's ABI stable.