3 ms·
The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the
by bluGill 3mo ago
The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the people who write that standard are very sensitive to the vendors and users of C++ who depend on a stable binary ABI. Thus they take extreme care to ensure that no change to the standard breaks binary ABI.
The C++ standard did force gcc to break the ABI of std::string (copy on write was banned - for good reason). They then watched the gcc community work through 10 years of pain to make the transition. They are also well aware that python 3 broke compatibility with Python 2 - and again it resulted in 10 years of pain for the python community to deal with that. With this history there are a lot of experts strongly against any breaking change. It might happen anyway, but only with strong justification and likely an attempt at a migration of some form (what? there are a lot of examples of migration plans that don't work that they are aware of)
Again, it is not because of convention, it is because of painful experience from those who break it.
- MFHava 3mo ago> They then watched the gcc community work through 10 years of pain to make the transition. During the same time the MSVC compiler broke ABI multiple times and the world didn't end. The fact that breaking ABI was such a shitshow for libstc++ is more related to the way C++/ABI/SOs is/are handled in Linux...
- plorkyeran 3mo agoIn the time since that VC++ has switched to a frozen ABI model that’s much closer to what Linux distros have. Each version of VC++ being ABI-incompatible and requiring each application to be built with a single version and ship its c++ runtime had some significant pros and cons. Microsoft never said it outright, but I’ve always assumed the major con that made them switch was that people didn’t buy new Visual Studio versions because upgrading VS required also upgrading all of your binary blob closed-source dependencies.
- Maxatar 3mo agoThe reason the world didn't end is because people refused to upgrade Visual Studio, in particular Microsoft's bigger customers. Microsoft surveyed their users for why people weren't making the switch to VS 2013 despite all the "nice" and "new" features introduced and the predominant reason was due to all the ABI breakages. For VS 2015 they adopted a policy of having a stable ABI and have preserved ABI compatibility for over 10 years now [1]. [1] https://devblogs.microsoft.com/cppblog/binary-compatibility-and-pain-free-upgrade-why-moving-to-visual-studio-2017-is-almost-too-easy/ https://devblogs.microsoft.com/cppblog/binary-compatibility-...
- p_l 3mo agoThe part where Windows applications built with C++ generally do not share C++ ABI DLLs with each other and the operating system except for certain well isolated ones is major part of it. GCC changing C++ ABI usually meant horrific time for every C++ application on Linux unless you use something like Nix so you don't chance loading incompatible binaries.