> Who wouldn't be using a C++17 compiler?

Tons of people. Anyone using an sdk for embedded or targetting older distros or OSs where upgrading runtimes are really under-prioritized by PLM.

> Tons of people.

The fact that you can find "tons" of these people only means C++ is very popular: by percentage they are going to be tiny.

> Anyone using an sdk for embedded...

Sure, if you are targeting some particularly unpopular microcontroller--one that isn't supported by gcc--and yet are somehow coding in C++, sure... but this category of C++ user barely exists.

> ...or targetting older distros or OSs where upgrading runtimes are really under-prioritized by PLM.

No: I am one of those people who "target older distros or OSs"! A lot of my users are currently on CentOS 6. Software I write is routinely deployed on like, macOS 10.6 (I don't currently support PowerPC so I can't go much lower, but this is mostly due to a lack of hardware on my end) and Windows XP; and yet I have never been locked away from a compiler feature (though it can sometimes get super annoying to support older systems and also use newer platform features, that is the opposite problem).

So: how do I do it? I just use a newer compiler! Newer compilers target old systems just fine. You just need an old sysroot. As mentioned: Xcode can be somewhat annoying because Apple likes to take advantage of LLVM being not-GPL sometimes to hide things for a while (like their arm64 backend), and they are really bad at basic software architecture principals (even their command line tooling often requires new operating systems), and yet even there: you can use newer workstations to compile for older systems; "worst case" (again: only when dealing with Apple) you also have to compile your own copy of libc++ so you can statically link it (as sometimes features of the compiler are tied to the standard library, and Apple incorrectly models the C++ runtime as part of the operating system instead of as part of the compiler or SDK).

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)

> 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.)

In 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.

I 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).

Yes, 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.

GCC 7 is available for RedHat 7 from an official package; it’s just not the default /usr/bin/gcc.