2 ms·

> 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 real

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

saurik 5y ago
> 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).

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

saurik 5y ago

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