Shall we start using C++17 at the master branch?

In the last few days, I prepared a pull request to upgrade the ITK master branch to C++17, with help from @dzenanz and @mihail.isakov Please check: PR #3969 ENH: Upgrade ITK from C++14 to C++17 by N-Dekker · Pull Request #3969 · InsightSoftwareConsortium/ITK · GitHub

C++17 is a major step forward. It includes quite a few interesting new features: C++17 - Wikipedia

However, moving forward to C++17 would also mean saying goodbye to a few old compiler versions. I think we should then at least require GCC 7, LLVM Clang 5, Apple Clang 10 (Xcode 10.0), VS2017 version 15.7, or Intel C++ 19.1, and drop support for earlier versions. Would that be OK?

3 Likes

@Niels_Dekker et al thanks for looking into this, submitting a PR, and creating this thread!

I have been using C++17 with ITK for quite some time, and it does have very nice advantages.

There is not a ITK/toolchain usage scenario I am aware of where the toolchain cannot be upgraded to support C++17 when upgrading ITK.

When upgrading the required standard version, we should also make a note in the ITK Software Guide and describe the associated minimum compiler versions here:

2 Likes

Thanks Matt. I believe that the required compiler versions that I proposed with PR #3969 basically support all C++17 language features. For some of the C++17 std library features, even more recent compiler versions may be needed. For example, std::filesystem is added with GCC 8, whereas the PR only requires GCC 7. And clang still does not support the parallel C++17 algorithms from <algorithm>. For details, you may have a look at Compiler support for C++17 - cppreference.com of course!

Note also that the PR still supports VS2017 (at least from version 15.7), even though I wouldn’t mind dropping that one either :smiley_cat:

So I just want to say that PR #3969 is quite a modest proposal :innocent:

I want std::filesystem to be available. It is one of the major additions to C++17. Can you update the PR to require GCC 8?

GCC 8 would be OK to me as well, thanks @dzenanz, but then, why not require at least GCC 9? GCC 9 has some more C++17 library features, as you can see at Compiler support for C++17 - cppreference.com GCC 9 was released almost four years ago already, and according to GCC 9 Release Series - GNU Project it has:

Runtime Library (libstdc++)

  • Improved support for C++17, including:
    • The C++17 implementation is no longer experimental.
    • Parallel algorithms and <execution> (requires Thread Building Blocks 2018 or newer).
    • <memory_resource>.
    • Using the types and functions in <filesystem> does not require linking with -lstdc++fs now.

At the elastix CI, we use GCC 9.4.0 on Ubuntu 20.04, so that’s no problem.

1 Like

I would be fine with that, too.

As @Niels_Dekker mentioned, filesystem support and parallel algorithm support, while wonderful to have as @dzenanz pointed out, are not currently broadly available, and we should not require it. They could optionally be used when available, but I do not think we can require them at this point.

OK, then, GCC7 now, and GCC9 an ITK version or two later :smiley:

1 Like

So with this proposal we are not going to be able to purely adopt CXX 17. What does this mean for how ITK will work with CMake to ensure the required features are there? Currently its easy to do something like: target_compile_features( SimpleITKIO PUBLIC cxx_std_14 ) Are we going back to explicitly listing the C++ compile features ITK requires?

As it relates to applications that use ITK:

Therefore the move for ITK to move to C++17 is fine on the 3D Slicer side :+1:

2 Likes

With the currently proposed minimum required compiler version, all C++17 language features will become available. Only a few C++17 std library features may then not yet be used, within the implementation of ITK. (This is just a limitation to ITK developers. ITK users do not need to be bothered, as they may have a newer compiler version for their application.)

Specifically, GCC 7 has all the C++17 language features, but its C++17 std library is still incomplete and “experimental”. So personally I would like ITK to move forward to GCC 9. But I don’t know if there are still ITK users out there using GCC 7 or GCC 8, do you?

If there are still ITK users that are using GCC 7 or GCC 8, I’m OK with requiring GCC 7 for now.

1 Like

I was looking for the current CMake best practices for these types of required features. It looks likes some answers can be found here:
https://cmake.org/cmake/help/latest/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html?highlight=lambda

In particular:

These individual features are now less relevant and projects should generally prefer to use the high level meta features instead. Individual compile features are not provided for C++ 17 or later.

So it sounds like the suggestion to just do: target_compile_features( mylib PUBLIC cxx_std_17 ) even if the compiler has an incomplete std library for the standard.

GCC 7 is the default version in Ubuntu 18.04, and there are still some people using it, but it is near End of Life (EOL).

1 Like

Standard support of 18.04 ends on May 31, 2023. What is the target date for the next release? If it is after that date does it still need to be supported by ITK?

The full EOL with Ubuntu Pro is extended to 2028.

We are looking at June for ITK 5.4, but I done not think bumping required GCC beyond 7 is going to address the std completeness issue – e.g. filesystem support is still newer across toolchains and it is not available in wasm toolchains, possibly others.

Thanks Matt, can you possibly make that a PR for ITKSoftwareGuide?

Done here:

2 Likes

@matt.mccormick @dzenanz As it is one year later now, would it be about time to drop GCC 7, and maybe move forward to requiring at least GCC 9?

As @blowekamp remarked at Use PathType for file paths by blowekamp · Pull Request #2085 · SimpleITK/SimpleITK · GitHub

The big hold out there was Ubuntu 18.04, which is now EOL’d.

The next release candidate is expected soon, so maybe after that? I primarily use Windows, so I don’t have a strong opinion about minimum GCC version, aside from “higher is better” :smiley:

1 Like

Another release candidate? I am not sure why actually releases are not occurring.

More specific to the point, I would expect the requirements for the next release (non-RC) to be set, and after the release the build requirements may change.