4 ms·

60% of developers are on C++17 and C++20, really? I would have bet that the vast majority of C++ projects are not using the latest standard let alone the lates

60% of developers are on C++17 and C++20, really? I would have bet that the vast majority of C++ projects are not using the latest standard let alone the latest compilers that support it.

saurik 5y ago
(I have been programming in C++ for just under a quarter of a century now--since before C++98 was standardized--and have seen a lot of C++ upgrades over the years.) Who wouldn't be using a C++17 compiler? AFAIK all relevant compiler franchises have supported almost all of C++17 for a long long time now (and unless you are screwing around with Xcode--as Apple doesn't seem to know how to separate applications from operating systems ;P--you generally don't have to upgrade anything except your compiler to upgrade your compiler). You have to be using C++ on a particularly unpopular microcontroller to be stuck without a modern C++ compiler (and even then).
- 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 ago
    GCC 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 ago
      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.
      - saurik 5y ago
        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).
        pjmlp 5y ago
- goalieca 5y ago
  > 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).

60% of developers are on C++17 and C++20, really? I would have bet that the vast majority of C++ projects are not using the latest standard let alone the latest compilers that support it.

saurik 5y ago

(I have been programming in C++ for just under a quarter of a century now--since before C++98 was standardized--and have seen a lot of C++ upgrades over the years.) Who wouldn't be using a C++17 compiler? AFAIK all relevant compiler franchises have supported almost all of C++17 for a long long time now (and unless you are screwing around with Xcode--as Apple doesn't seem to know how to separate applications from operating systems ;P--you generally don't have to upgrade anything except your compiler to upgrade your compiler). You have to be using C++ on a particularly unpopular microcontroller to be stuck without a modern C++ compiler (and even then).

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