6 ms·

Even for fully statically typed languages like C++, it is very common that some old code can’t compile with latest compiler. Shrugs.

IshKebab 6y ago
No it isn't. C++ has extremely good backwards compatibility.
- nyanpasu64 6y ago
  Even aside from deliberate backwards-compatibility breaks in the standard, compilers sometimes break compatibility. Both MSVC and GCC 11 have changed their header file transitive includes within the past few years, causing projects (like doctest and Qt5) to stop compiling because they forgot to include headers, which built fine in the past but not anymore. IDK if it's "very common", but it's definitely happening in the wild. MSVC: https://github.com/onqtam/doctest/issues/183 https://github.com/onqtam/doctest/issues/183 GCC: - https://invent.kde.org/qt/qt/qtbase/-/commit/8252ef5fc6d043004ddf7085e1c1fe1bf2ca39f7 https://invent.kde.org/qt/qt/qtbase/-/commit/8252ef5fc6d0430... - https://invent.kde.org/qt/qt/qtbase/-/commit/cb2da673f53815a5cfe15f50df49b98032429f9e https://invent.kde.org/qt/qt/qtbase/-/commit/cb2da673f53815a...
- volta83 6y ago
  I disagree. C++ often removes language features, standard library features (std::random_shuffle), etc. Also object files compiled with different standard versions often are ABI incompatible with each other, which means you can't just pick new C++ for new code, but its rather all or nothing. You can argue that when it removes features it provides a replacement (sometimes), but that does not change the fact that if you have any reasonably large project (>1 million LOC), every standard upgrade will break your app. One of the main reasons we write all new code in Rust and are migrating the C++ code base step by step to Rust is because Rust offers infinitely better backward compatiblity guarantees than C++. Rust never ever breaks your code, and you can opt-in to newer Rust editions for new code only, and these are ABI compatible with Rust code written using older editions.

IshKebab 6y ago

No it isn't. C++ has extremely good backwards compatibility.

nyanpasu64 6y ago
Even aside from deliberate backwards-compatibility breaks in the standard, compilers sometimes break compatibility. Both MSVC and GCC 11 have changed their header file transitive includes within the past few years, causing projects (like doctest and Qt5) to stop compiling because they forgot to include headers, which built fine in the past but not anymore. IDK if it's "very common", but it's definitely happening in the wild. MSVC: https://github.com/onqtam/doctest/issues/183 https://github.com/onqtam/doctest/issues/183 GCC: - https://invent.kde.org/qt/qt/qtbase/-/commit/8252ef5fc6d043004ddf7085e1c1fe1bf2ca39f7 https://invent.kde.org/qt/qt/qtbase/-/commit/8252ef5fc6d0430... - https://invent.kde.org/qt/qt/qtbase/-/commit/cb2da673f53815a5cfe15f50df49b98032429f9e https://invent.kde.org/qt/qt/qtbase/-/commit/cb2da673f53815a...
volta83 6y ago
I disagree. C++ often removes language features, standard library features (std::random_shuffle), etc. Also object files compiled with different standard versions often are ABI incompatible with each other, which means you can't just pick new C++ for new code, but its rather all or nothing. You can argue that when it removes features it provides a replacement (sometimes), but that does not change the fact that if you have any reasonably large project (>1 million LOC), every standard upgrade will break your app. One of the main reasons we write all new code in Rust and are migrating the C++ code base step by step to Rust is because Rust offers infinitely better backward compatiblity guarantees than C++. Rust never ever breaks your code, and you can opt-in to newer Rust editions for new code only, and these are ABI compatible with Rust code written using older editions.