Should we remove option ITK_USE_CONCEPT_CHECKING
and always use concept checking in classes? Were there other use cases for this option besides inconsistent support in older compilers?
It used to be inconsistent support in compilers.
The only concern now is build time (?).
It may be reasonable to remove the option if build times of large projects like Python wrapping, Slicer, etc. are not significantly effected in their build time.
Personally I wouldn’t mind if updates on ITK concept checking would be postponed until concepts are standardized in C++ (both the language and the std library). Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018 (searching for “concept”), there still appears a lot of progress in that area.
In the meantime, it seems to me that C++11 static_assert
and <type_traits>
could already be helpful to do similar checking. For example:
static_assert(std::is_convertible<int, TOutputPixelType>::value,
"IntConvertibleToOutputCheck");
Appears similar to:
itkConceptMacro( IntConvertibleToOutputCheck,
( Concept::Convertible< int, TOutputPixelType > ) );
From the class definition of HoughTransform2DCirclesImageFilter:
My 2 cents
Refactoring concept checks themselves is something we should do too. static_assert
should be quite useful there, both for friendlier error messages and faster compile times.