4 ms·
Then upgrade their compilers, it's not as big a jump as c++11 was. It's not bleeding edge. The only legitimate case I've seen for C++ <17 is if you need to com
by qppo 6y ago
Then upgrade their compilers, it's not as big a jump as c++11 was. It's not bleeding edge.
The only legitimate case I've seen for C++ <17 is if you need to compile on MacOS <= 10.13 for shipping 32 bit binaries on Mac, where C++17 features are experimental in XCode (but I haven't had an issue with compatibility in C++17 supported compilers).
CentOS and Debian shipping ancient GCC versions isn't an excuse, it's trivial to update.
- rumanator 6y ago> Then upgrade their compilers If only life was that simple.
- cozzyd 6y agoFor me, yes (I often compile my own gcc). For $USER on $RANDOM_CLUSTER_AT_OTHER_UNIVERSITY_THAT_I_CANT_LOG_INTO, somewhat less easy :).
- ncmncm 6y agoFor the record, CentOS 7 can have gcc-9 by installing devtoolset-9. To get access, you have to start a shell that can see them with "scl enable devtoolset-9 bash". But people delivering libraries to customers who have elected not to upgrade to current releases are pretty much stuck. It is extremely common for banks, in particular, to still be running gcc-4, and to have no plans ever to upgrade. It is common at least in banks to have an unbreakable policy never to upgrade software on a server to a version that was not on it when it was unboxed. They may bend just so far as to install back-patched security fixes from the vendor. But a libstdc++.so compatible with a current language Standard? Haha, they say, you must be joking. It is not unusual for them to still run RHEL 6, or even 5. Bloomberg infamously still has 32-bit SPARCs in the basement, running code compiled only ever with Sun's old compiler.
- hoistbypetard 6y agoI had a celebration the day I could push RHEL5 builds off the compatibility raft. Then I spent a couple weeks learning about "new" C++ features I hadn't been able to use because it was too hard to ship code that a customer could build on RHEL5.