C++ standard to use

[BsAtHome]

The configure script tests for c++17 (AX_CXX_COMPILE_STDCXX(17, , mandatory) in src/configure.ac:42. However, the src/Makefile:258 sets the standard to gnu++20.

If the standard is supposed to be c++20 (with gnu extensions), then it must be tested in configure. For the current build, I suggest to use --std=c++17 to be compatible with clang and change the Makefile accordingly.

Other suggestions?

[rene-dev]

Its supposed to be 20, please change the configure script accordingly.

[rmu75]

so can we finally use std::span and std::format?

[BsAtHome]

Its supposed to be 20, please change the configure script accordingly.

Debian Bullseye, which is a supported platform afaik, uses g++ 10.2, which does not fully support c++20. It is however c++17 feature complete. That would suggest that setting the standard to c++20 is inappropriate.

[rmu75]

We should stay with c++20 even if it is not completely supported on current build platforms, things like concepts, improved constexpr and consteval are useful language features supported by even gcc-10. https://gcc.gnu.org/projects/cxx-status.html

IIRC concepts are already used, so that ship has sailed anyways...

[andypugh]

Debian Bullseye, which is a supported platform afaik, uses g++ 10.2, which does not fully support c++20. It is however c++17 feature complete. That would suggest that setting the standard to c++20 is inappropriate.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions agrees with you.

But then the question is whether we want to continue to support Bulleye. Master was supported in Buster until Rene changed it during the Norway meetup last year (or the year before...)

Trixie will almost certainly be out before 2.10 is released.

[rmu75]

Is there a scenario where bullseye works on a machine and upgrade to bookworm would not be possible?

[BsAtHome]

A non-upgrade scenario can be some hardware no longer updated/supported in newer distros (like proprietary [graphics] drivers). But then again, the LCNC code might be fixable if ultimately necessary, even with incomplete c++20 compiler support.

So it seems to be decided then... C++20 it is.

BTW, a lot of other --std version flags were seen while sorting out shellcheck problems. These may also need a review in due time.

[smoe]

Once the shellcheck-triggered changes are in, I guess more work on cppcheck will be addressed. Maybe the one or other C++-17/20 feature will sneak in while reviewing all that code.

[BsAtHome]

Once the shellcheck-triggered changes are in, I guess more work on cppcheck will be addressed. Maybe the one or other C++-17/20 feature will sneak in while reviewing all that code.

Yes, it probably will align more closely to newer standards. I already have a whole bunch of fixes in my tree...

Adding the C++20 standard will be part of that too. However, it must be noted that older cppcheck does not support C++20. I have to check which distros may give problems.

[smoe]

The cppcheck is not part of a regular build. We should be fine.

[BsAtHome]

Just tested a version for C++20 in configure and it fails CI on Bullseye (Debian 11):

...
checking whether c++ supports C++20 features by default... no
checking whether c++ supports C++20 features with -std=gnu++20... no
checking whether c++ supports C++20 features with -std=c++20... no
checking whether c++ supports C++20 features with +std=c++20... no
checking whether c++ supports C++20 features with -h std=c++20... no
configure: error: *** A compiler with support for C++20 language features is required.
...

The consensus is that C++20 is required, so we need to drop Bullseye/Debian 11. The upcoming PR will update CI to drop it from the tests.

[smoe]

From https://gcc.gnu.org/projects/cxx-status.html : To enable C++20 support, add the command-line parameter -std=c++20 (use -std=c++2a in GCC 9 and earlier) to your g++ command line. Or, to enable GNU extensions in addition to C++20 features, add -std=gnu++20.

Bullseye ships with gcc-10 (https://packages.debian.org/source/oldstable/gcc-10), it may just be a problem of configure / dependency settings?

[BsAtHome]

The configure test does not consider gcc-10 a viable c++20 compiler. It uses the AX_CXX_COMPILE_STDCXX macro from the m4 directory (m4/ax_cxx_compile_stdcxx.m4). Apparently, it tests using -std=gnu++20 and -std=c++20.

[BsAtHome]

And adding "2a" to the list of alternatives results in:

...
checking whether c++ supports C++20 features by default... no
checking whether c++ supports C++20 features with -std=gnu++20... no
checking whether c++ supports C++20 features with -std=gnu++2a... no
checking whether c++ supports C++20 features with -std=c++20... no
checking whether c++ supports C++20 features with +std=c++20... no
checking whether c++ supports C++20 features with -h std=c++20... no
checking whether c++ supports C++20 features with -std=c++2a... no
checking whether c++ supports C++20 features with +std=c++2a... no
checking whether c++ supports C++20 features with -h std=c++2a... no
configure: error: *** A compiler with support for C++20 language features is required.
...

This is Debian 11:

$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110
[snip]
$ lsb_release -d
Description:	Debian GNU/Linux 11 (bullseye)

[smoe]

From https://gcc.gnu.org/onlinedocs/gcc-10.5.0/gcc/Standards.html#C_002b_002b-Language, please try -std=c2x.

Edit - sorry, this was in the C-section of that manual - sigh.

[BsAtHome]

Edit - sorry, this was in the C-section of that manual - sigh.

And, it takes from the manual from 10.5 (Bullseye is at 10.2). But even in your linked manual in the c++ section, there is no c++20 variant mentioned.

[BsAtHome]

Edit: it does work with clang.

[smoe]

How do you folks feel about providing packages for older distributions with statically linked executables? For regular Linux kernels I would not worry, but the real-time extension may be incompatible?!

Edit: This way the older machines would still be supported. Contribtions to the current code base for anything scripted could still happen.