[Insight-developers] Adding Concept Chechking "float"/"double" to pixel type of GradientAnisotropicDiffusion

[Luis Ibanez]

Hi Bill,


Thanks for all the feedback:

It seems that three options have been suggested:

     1) Add the Concept Check (compile time error message)
     2) Display an error/warning message at run time
     3) Add an internal casting to real type


 From these options,

   (1) Is not backward compatible. It would have been
       the right technical solution, if we have added
       from the beggining. Now seems to be too late.

   (2) Is backward compatible, but may not get enough
       attention, and it doesn't really solve the problem.

   (3) Seems to be the only one that truly solves the problem.
       It has the advantage of being Backward compatible, and
       will make the filter usable for all pixel types.


If there are no objections, I'll add a bug to the MANTIS
bug tracker and explore a way of inserting two casting
filters inside the filters that use the PDE solvers.
The trick is to find a way of only casting when necessary,
so there is no penalty for those how instantiate the filter
using float/double image.


    Thanks


       Luis


---------------------
Bill Lorensen wrote:
> Steve,
> 
> Here is the pointer to the ITK backward compatibility document (draft): 
> http://www.insightsoftwareconsortium.org/wiki/index.php/Administration-BackwardCompatibility 
> <http://www.insightsoftwareconsortium.org/wiki/index.php/Administration-BackwardCompatibility>
> 
> Bill
> 
> On 8/15/07, *Bill Lorensen* <bill.lorensen at gmail.com 
> <mailto:bill.lorensen at gmail.com>> wrote:
> 
>     Steve,
> 
>     According to our backward compatibility policy, the introduction of
>     compiler errors should be avoided at all costs. A compiler error is
>     typically crytic especially in templated code. A runtime error
>     message can be very descriptive to the owner of the code. As you
>     stated, the development team failed to place this restriction on the
>     code originally. Often, the person recompiling the application code
>     may not be the same person who wrote the original application. Also,
>     some time may pass between version updates of third p[arty ( e.g.
>     ITK, VTK) code.
> 
>     Granted, there will be times when a compile error cannot be avoided,
>     but this should be a last resort.
> 
>     I was just going to quote the ITK Bacrwd Compatibility document, but
>     I'm emrassed to say, I can't find it on the internet. I'll track it
>     down...
> 
>     Bill
> 
>     On 8/15/07, *Steve M. Robbins* < steve at sumost.ca
>     <mailto:steve at sumost.ca>> wrote:
> 
>>  On 8/15/07 8:12 AM, "Bill Lorensen" <bill.lorensen at gmail.com
>         <mailto:bill.lorensen at gmail.com>> wrote:
>>
>>  > Luis,
>>  >
>>  > This change may cause backward compatibility problems. Old
>         code may no longer
>>  > compile and the compiler error for the conept checking is
>         cryptic on some
>>  > compilers. We should warn the user and give explicit
>         instructions on how to
>>  > repair the code in the warning message.
>>  >
>>  > I understand that the current code is not producing correct
>         results. But that
>>  > is the fault of the itk development team and not the user of
>         the code. We
>>  > should notify users in an instructive way on how to fix
>         their code so that it
>>  > produces correct results. A cryptic compiler error is not
>         informative.
> 
>         For my curiousity only: how is it a failure of the ITK
>         development team?
>         Naively, it seems the failure is not to have had the concept
>         checking
>         from Day 1.  Or did you have something else in mind?
> 
>         For what it's worth (not being an ITK developer and never having
>         seen
>         the fallout of a concept check failure), I tend to agree with Luis.
>         IMHO, it is better to have the build fail than the execution
>         because
>         the user may not be in the position to fix the error, assuming they
>         see the message at all.
> 
>         Regards,
>         -Steve
> 
>         -----BEGIN PGP SIGNATURE-----
>         Version: GnuPG v1.4.6 (GNU/Linux)
> 
>         iD8DBQFGwyZN0i2bPSHbMcURAtAaAJ4qVgiuaetMmebNEezc2JIxg8qzeACeJt6Q
>         xH09gWNN53ryTkubhSukdxI=
>         =lyp8
>         -----END PGP SIGNATURE-----
> 
>         _______________________________________________
>         Insight-developers mailing list
>         Insight-developers at itk.org <mailto:Insight-developers at itk.org>
>         http://www.itk.org/mailman/listinfo/insight-developers
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers