5 ms·
There is no danger of C++20 modules failing to "gain traction". They are already in the Standard. All that is left is to define Standard module names for the St
by ncmncm 5y ago
There is no danger of C++20 modules failing to "gain traction". They are already in the Standard. All that is left is to define Standard module names for the Standard library components.
Most likely that will be, simply, "import std" in almost all cases, with no reason for finer granularity.
Of course we will need to update our non-Standard libraries to get the benefits there. That will happen fast once more compilers finish implementing C++20 features.
- deutschepost 5y agoFor me at least, it seems like development on the build system side is very slow. The relevant ticket in the CMake Repository[1] is more than three years old for a critical functionality. There are efforts to make an open interface between Compiler and Build System[2] but these are non-standard and for now it seems like there is not "one good way" to do modules. For example it is possible to do modules with the CMake MSVC Generator[3] but I can't use Ninja when working with MSVC. [1]https://gitlab.kitware.com/cmake/cmake/-/issues/18355 https://gitlab.kitware.com/cmake/cmake/-/issues/18355 [2]https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1689r4.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p16... [3]https://devblogs.microsoft.com/cppblog/cpp20-modules-in-cmake-with-vs/ https://devblogs.microsoft.com/cppblog/cpp20-modules-in-cmak...
- duped 5y agoOne compiler implements module support to the point it's useful, and that compiler targets one operating system. I don't think it's hard to fathom that C++ modules might not gain traction when there is little indication of adoption in compilers, let alone code based that could benefit them.
- ncmncm 5y agoThey cannot claim Standard conformance without implementing all required features. Furthermore, since Gcc and Clang are also coded on C++, they will not get the benefit of rebuilding the compiler much faster without implementing it.
- Shorel 5y agoThe GCC in CentOS 7 (what we use at work for being 'stable') doesn't even support C++14. In 2022.
- ncmncm 5y agoThis is meaningful, how? You are using a snapshot frozen years ago. Surprise, frozen thing is still frozen! You are of course able to build for frozen system with modern compilers (e.g. "dev-toolset-11". If you don't, it is because, and only because, your employer has chosen not to. My recommendation is, get a better employer.
- Shorel 5y agoI complained, and now I have an Amazon Linux 2 machine to play. Why the default is that horrible CentOS (I am an Ubuntu person), is beyond me. It's been decades since Oracle stopped being relevant (only reason to ever pick up a RedHat compatible distro, IMO).
- ncmncm 5y agoCentOS 8 was released (and itself frozen, except security patches) years ago. Current CentOS has been broken loose from RHEL, so if you need bitwise compatibility with RHEL 9, you will need to switch over to building for Rocky or Alma when you move off targeting 7 or 8. You can build for CentOS 7 in a docker image on your Amazon host, and also run Gdb on your Amazon host, using "target remote" to attach it to a gdbserver on your CentOS 7 target execution environment. I use sshfs on my host to map a directory on the target, so my builds put binaries over there automatically.
- Shorel 5y agoThe issue is: I am testing graviton instances, because they are supposedly cheaper than Intel/AMD ones. Some 'normal' libraries still don't exist for ARM, and I have to compile more stuff myself. My own C++ code is the one requiring GCC 5 or higher.