[Insight-users] posssible bug in ÎTK 3.18

[Neuhaus Jochen]

Hi List,


I have a simple test program that produces compiler errors with ITK 3.18 in Debug mode (on Visual Studio 2008), but was working with ITK 3.16:

#include <itkNonUniformBSpline.h>
int main(int /* argc */, char* /*argv*/[])
{
  typedef itk::NonUniformBSpline<3> SplineType;
  SplineType::Pointer mySpline;
  return 0;
}


itkNonUniformBSpline.h changed between 3.16 and 3.18 to use itkGetConstReferenceMacro instead of direct inline Get-methods (see bug http://public.kitware.com/Bug/view.php?id=10458). The problem is, that the type if the member that is returned is not an itk-type, but stl::vector. Inside itkGetConstReferenceMacro, in Debug mode, the stl vector is piped into an itk::OStringStream:

itkDebugMacro("returning " << #name " of " << this->m_##name );

<-- this produces an compiler error that there is no valid << operator.

Unfortunately, there is no unit test for itkNonUniformBSpline and the class is not used anywhere in ITK, therefore it was probably never compiled by a dartclient. Another example that untested code is to be considered buggy code...

However, we use this class in our MITK toolkit, which makes MITK incompatible with ITK 3.18.

This bug is easy enough to fix (use itk::VectorContainer instead of stl::vector), but the question is, will there be a bugfix release of ITK for this in the not too distant future that we could wait for? Or should we try to circumvent this on the MITK side to establish compatibility with ITK 3.18?


Best Regards,
 Jochen