3 ms·
I am double checking. - Full C++17 support requires GCC 7 or Visual Studio 2019 or Clang 5. - Limited support available in GCC 5 and Visual Studio 2017 with u
by user5994461 5y ago
I am double checking.
- Full C++17 support requires GCC 7 or Visual Studio 2019 or Clang 5.
- Limited support available in GCC 5 and Visual Studio 2017 with update pack.
Then the question is what packages are available in Debian/RedHat? especially the previous major version of the OS (Companies are always slow to upgrade and libraries in particular need to work on active OS until EOL).
RedHat 7 is stuck on GCC 4.8 so anybody working in that type of environment is stuck there. Debian looks fine. For Visual Studio it probably depends on whether you can get the license (have to convince procurement to pay?)
Aside of the tooling, you have to take time and be willing to upgrade the toolchain. I'd expect C++ to be the language with trillion of lines of barely maintained legacy code. (We can define "legacy" as any existing code :D)
- ericbarrett 5y agoGCC 7 is available for RedHat 7 from an official package; it’s just not the default /usr/bin/gcc.
- saurik 5y ago> RedHat 7 is stuck on GCC 4.8 If you are actually maintaining a large C++ codebase and all your workstations are required to run RedHat 7 for some reason, you download a newer version of GCC and run it on RedHat 7. RedHat 7 is not "stuck on" GCC 4.8. (And I don't just mean that "you can get newer official compiler packages from RedHat and you just don't know it", like the other reply says: you can install a new version of GCC even if that weren't the case.) And in case anyone's mind goes here: newer versions of GCC aren't incapable of generating binaries that run on older systems, either; a large number of my users are using CentOS 6 (yes: 6) and I use the latest bleeding edge compiler to compile my code. (The secret--which I assure you most of the people who do extensive maintenance work knows--is you always "cross-compile" your binaries for Linux, even if you are on Linux already, so you have complete control over the deployment glibc version.)
- pjmlp 5y agoIn most enterprises you don't download anything if you want to keep your job. Additionally, exactly to prevent the clever ones that still do it anyway, Developers get their own group id and HOME is mounted as no exec. Naturally I am speaking about typical UNIX shops were contractors get to SSH into the official development boxes.
- saurik 5y agoI mean, good luck building typical Unix projects in a directory mounted non-executable... having build steps that generate binaries that build other binaries is like, "the name of the game". Is this your experience, or are you just surmising this? If the former, how did that even work? In my long experience (which has included working on embedded systems for a large highly-boring multinational company: Bosch) it is more likely that the organization will literally vendor the compiler--which is the best strategy for making sure that your code will still be compilable forever--than insist that their engineers not be able to run code on their laptop (though they certainly had extremely tight control over networking and data movement).
- pjmlp 5y agoYes, that was my experience back when stuff like HP-UX, Aix and Solaris was commonly deployed. There is no laptop to run code on, laptop is only for SSH and X Windows server, or cloud shell in modern "mainframes". Nowadays one can make it one level up my having a CI/CD wall between the development environment and the actual stages, thus whatever one uses to develop must also be available on the stages, which contractors can only access with the help of hands from internal employees.