Ease transition to const-correct VerifyPreconditions


(Dženan Zukić) #1

All the code which overrode VerifyPreconditions() and VerifyInputInformation() now fails to compile with an error message similar to this:

16>c:\misc\bluequartz\simpl\source\simplib\itk\itkinplaceimagetodream3ddatafilter.h(57): error C3668: ‘itk::InPlaceImageToDream3DDataFilter<TPixel,1>::VerifyPreconditions’: method with override specifier ‘override’ did not override any base class methods

We could introduce a macro which would be const with legacy off, and [empty string] with legacy on. We could call it ITK5_CONST or something similar. Alternatively, we could remove const from the signatures of those two methods.


(Simon Rit) #2

I have had some trouble with this, see this commit. In general, I think that those backward incompatible changes should be avoided (and this thread should have started before committing these changes). Particularly since we cannot add tests on ITK_*_VERSION in the code with all 5.* versions having the same numbers (there has not been a non-alpha or non-beta release in a long time). I don’t think that the legacy on/off is a solution, in practice some people will report that the code does not compile with ITK_LEGACY_REMOVE.


(Niels Dekker) #3

I think that might work, for me at least. :grinning:

But then, when would there be a better moment to fix const-correctness of VerifyPreconditions() and VerifyInputInformation()?

By the way, there could be another workaround to ease the transition: offer both const and non-const overloads of these two virtual member functions, in the base class (itk::ProcessObject). The non-const versions could then internally call the corresponding const versions. And ITK users could then override either one of them. (Of course, it would be recommended to override the const versions.)

My 2 cents


(Dženan Zukić) #4

I am not sure whether that could work, and what would be the side-effects and future maintenance burden of that. But it is an idea I haven’t thought of!


(Bradley Lowekamp) #5

I agree with the expected behavior with the following CMake variables:

  ITKV4_COMPATIBILITY:BOOL=ON
  ITK_LEGACY_REMOVE:BOOL=OFF

is that the old non-const methods should work. I did briefly implement the non-const versions calling the const versions in the ProcessObject, but that was riddled with warnings or error dues to incomplete overloads.

If something like ITKv5_CONST is added please also add it to the v4 release branch so it can be used for v4 and v5 code.


(Dženan Zukić) #6

OK, I am implementing the macro solution. I will call it ITKv5_CONST.


(Dženan Zukić) #7

PR here.

TODO: add #define ITKv5_CONST to itkMacro.h in release-4.13 branch.