Now that ITK 5.2 is released, may we start using C++14 features at the master branch of ITK?
It is now more than three years ago that ITK (master) moved from C++98/ C++03 to C++11:
Obviously it’s a much smaller step to move forward from C++11 to C++14. But still, C++14 has a few extra features that very much ease writing better code: C++14 - Wikipedia
So please consider:
Requiring C++14 would imply we drop support for Visual Studio 2015. Do we want to do that? Allowing most of C++14 features would allow us to keep supporting VS2015. Other compilers have had C++14 support for a while now.
EDIT: We would need to add a nightly build with VS2015 to check compliance, in case we want to keep supporting it.
Thanks for your feedback @dzenanz We dropped Visual Studio 2013 more than three years ago already: New Build Errors on CDash 1/24/18 - drop support for VS2013 in ITKv5?
So maybe it’s about time to drop VS2015 now. Especially because VS2017 and VS2019 have been around for quite a while now.
However, if it’s really necessary to keep supporting VS2015 for a while, it would still be great if we could already start using the C++14 subset that is implemented by VS2015. The most significant missing C++14 language feature would then be “Extended constexpr”, as I see at the link you added, C++ compiler support - cppreference.com
I don’t think I have VS2015 installed any more. Supporting it is not important to me - but it might be to someone else. As VS2017 and 2019 are backwards compatible with VS2015 CRT, I am not sure how big of an issue dropping VS2015 support might be. I would like more people to express their opinion.
Just added an extra commit to the pull request, proposing to move the minimum required compiler versions from GCC 4.8 to 5.1, from Clang 3.3 to 3.4, and from Intel 14.0 to 17.0: COMP: Require compiler versions that support C++14
While I would like to also move from VS2015 to VS2017 as minimum required compiler version, we may also still postpone Visual Studio upgrade for a little while, of course.
Niels, what change to minimum Xcode version are you proposing here?
Xcode 5.1. As far as I know, that’s the very first Xcode version that supports C++14. Would that be acceptable to you?
Hello,
Microsoft Visual C++ 14.x compiler is important to compile Python 3.5-3.8. Please note that VS2015 referrers to the GUI/install not the compiler tools which is the important thing here to support. You can configure the VS tool set to “v142,host=64” on VS2019.
In this table:
| Visual C++ | CPython |
|---|---|
| 14.X | 3.5, 3.6, 3.7, 3.8 |
| 10.0 | 3.3, 3.4 |
| 9.0 | 2.6, 2.7, 3.0, 3.1, 3.2 |
They call for compiler 14.X, and those are 2015 (14.0), 2017 (14.1) and 2019 (14.2). And we are already building Python packages using VS2019 in our remote module CI infrastructure.
With VS2019 you can install and compile with 14.0, 14.1, 14.2:
My primary point was that version of VS with the version of the compiler is no longer tied together. The compiler version is what is being depricated as you can use VS2019 with v14.0.
We are deprecating v140 compiler toolset which was released with and is the default choice in VS2015. I understood that.
I made an orthogonal remark that we can compile Python with VS2019, and its default toolset v142.
for a migration to C++14 as a minimum. I am not aware of a toolchain used in the community that is a blocker.
Xcode 5.1 or Apple Clang 5.1? Xcode versions and the C++ compiler versions are not the same.
From clang - Xcode 5.1 enable C++14 - Stack Overflow I understood that Xcode 5.1 allows using Clang 3.4, which supports C++14. But please correct me if I’m wrong!
The wikipedia page is also helpful:
https://en.wikipedia.org/wiki/Xcode#5.x_series
Bumping the requirement from Xcode 5.0 to 5.1 is pretty inconsequential, as that doesn’t increase minimum macOS needed to run. (newer Xcodes quickly drop support for older macOS)
And just to expand a bit on Xcode 5.x. It was released in 2013 for macOS 10.8/10.9. There have been 7 major versions of macOS released since then. I’ll go out of a limb and take a guess that almost* nobody is compiling ITK on a machine that old. And if they are, then I’d hate to hold up ITK development for someone compiling on a 7 year old macOS system. Yes sounds harsh, but ITK needs to move on.
Ideally these kinds of decisions would have taken place at the ITK 5.0 release instead of at minor releases such as 5.2 or 5.3.
With ITK 5.0 we moved from C++03 to C++11! Now, a few year later, we go from 11 to 14. Sounds about right to me 
Fair enough… 
(didn’t do my homework when I wrote that… )
The jump from 14 to 17 will be an interesting one, from a macOS perspective, as that will really jump you up macOS systems.
Hopefully, we will have dedicated funding for ITK within a few years, and we will be doing some other things such as build system makeover and better use of GPUs to justify jumping many versions. Plus, it will be a few years from now
All tests of the C++14 pull request (PR 2563) passed successfully at Azure Pipelines for ITK.Windows, ITK.Linux, ITK.Linux.Python, and ITK.macOS, but ITK.macOS.Python failed! Does anyone of you have a suggestion how to get it fixed? As I mentioned at ENH: Upgrade ITK from C++11 to C++14 by N-Dekker · Pull Request #2563 · InsightSoftwareConsortium/ITK · GitHub
With ITK.macOS.Python (Azure.Mac-1622623168201), a compilation error occurred at Modules/Core/Common/include/itkMacro.h:
# if defined(__clang__) && (__cplusplus < 201402L)
# error "Apple LLVM < 5.1 (clang < 3.4) is not supported under ITKv5.3"
As https://open.cdash.org/viewBuildError.php?buildid=7261181 says:
Modules/Core/Common/include/itkMacro.h:192:6: error: “Apple LLVM < 5.1 (clang < 3.4) is not supported under ITKv5.3”
Could it be that I did not properly properly set the compiler to C++14, for ITK.macOS.Python? If so, how could that be fixed?