Hacker News Reader

Comment by ncmncm | Hacker News Reader

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.

View on HN

For 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

[2]https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p16...

[3]https://devblogs.microsoft.com/cppblog/cpp20-modules-in-cmak...

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

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

Cool. They're still the standard compilers for C++ on major platforms and don't have full module support, and won't have it anytime soon.

You can make up any definition you like for "soon". And did.

The GCC in CentOS 7 (what we use at work for being 'stable') doesn't even support C++14. In 2022.

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

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

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

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

Again, there is no difficulty of any kind in using (say) Gcc-11 to build binaries to run on a stock CentOS 7 target. On CentOS (which user-space environment you would run in a docker image), I think the package you would need is dev-toolset-11. Look it up. (It is possible that is only in CentOS 8, so you might need dev-toolset-9 instead, which would serve.)

Reply on news.ycombinator.com