[Insight-developers] RE: concept checking and backward compatibility

[Amy Squillacote]

Hi Bill,

The class is itkBloxBoundaryProfileImageToBloxCoreAtomImageFilter (in 
Code/BasicFilters).  From talking with Luis about this class, I 
suspect that it is rarely used.  This class is templated over the 
image type and a separate dim value.  Both the dimension of the image 
and the dim value must be 3, so the second template parameter is 
redundant.  Since the dimension of the image template parameter must 
also be 3, effectively this class is only templated over the data 
type of the image.  I would prefer the second option described 
previously of removing the second template parameter.  Alternatively, 
we could change the code so it really is only templated over the data 
type of the imge, but this approach may be too aggressive.

- Amy

At 02:38 PM 2/20/2006, Lorensen, William E \(GE, Research\) wrote:
>Which class is it? If it produces a compiler error for n!=3 then 
>either choice is OK. What we don't want is code that used to compile 
>and will not compile with the changes.
>
>Bill
>
>-----Original Message-----
>From: Amy Squillacote [mailto:amy.squillacote at kitware.com]
>Sent: Monday, February 20, 2006 2:24 PM
>To: Lorensen, William E (GE, Research)
>Cc: insight-developers at itk.org
>Subject: concept checking and backward compatibility
>
>
>Dear Bill,
>
>As part the revision for introducing concept checking, we encountered
>the following case and we are wondering what is the appropriate way
>to proceed based on the backward compatibility polity.
>
>We have a class templated over an integer n, but the code will only
>compile when n is a specific value (in this case, 3).  We could
>introduce a new concept for a template parameter to be a specific
>value, or we could remove the template parameter and force n to be 3.
>
>The first option respects the API, but will be awkward because the
>class is not really general since only a single value of the template
>parameter is valid.
>
>The second option breaks the API, but can arguably be called a bug
>fix because the code is actually broken for other values of n.
>
>Please give us your input.
>
>- Amy