Always use concept checks?


(Dženan Zukić) #1

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?


(Matt McCormick) #2

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.


(Niels Dekker) #3

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. :grinning:

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


(Dženan Zukić) #4

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.