3 ms·
> You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every s
by nickysielicki 1y ago
> You're talking about production software, many of which has decades worth of commit history, which you simply cannot spend time going through each and every single line of code of your >1M LoC codebase.
They can keep using the old standard.
- motorest 1y ago> They can keep using the old standard. But they cannot upgrade. Ever. At least without requiring major maintenance work. Which means never. Do you understand what that means?
- nickysielicki 1y agoEvery compiler continues to support old standards. What risk am I missing? This feels like a perfectly acceptable outcome for icky legacy code that is not essential enough to maintain.
- SideQuark 1y agoNo they don't, not even close. Name a single long running compiler suite that can compile every version it once did.
- nickysielicki 1y agohttps://gcc.gnu.org/onlinedocs/gcc/Standards.html https://gcc.gnu.org/onlinedocs/gcc/Standards.html Is this inaccurate?
- SideQuark 1y agohttps://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html GCC rarely, like never, supports the complete standards. Every release improves conformance, fixes errors, sometimes drops support for targets, perhaps changes how poorly defined areas work. As a result, likely no version compiles code the same as a previous version across all possible code. You’ll also note GCC doesn’t likely compile the variants of C++ it did before the 1998 version. And this type of page is just the tip of the iceberg https://gcc.gnu.org/gcc-13/porting_to.html https://gcc.gnu.org/gcc-13/porting_to.html. You’ll note changes made that can render previously compilable code no longer compilable. So no, you cannot naively think a new compiler version will simply run all your old code. On big projects upgrading is a huge endeavor to minimize problems. We could do every supported language the same way.