[Insight-developers] Link errors and itk::NumericTraits on Windows

[Zachary Pincus]

Hi folks,

I assume everyone agrees that there is a problem in ITK with the  
NumericTraits specializations for compound types?

(Summary: special NumericTraits headers need to be explicitly  
#included for compound pixel types, but this causes problems for  
generic template classes that want to just #include a generic  
NumericTraits header.)

It would seem that there are two possible solutions, both with  
downsides that Kent pointed out:

(1) Make itkNumericTraits.h include other itkNumericTraitsXXXPixel.h  
headers. This is bad because it causes more headers to be included  
than potentially necessary, and it can cause maintenance problems  
(what if a new itkNumericTraitsXXXPixel.h is added, but
not included by itkNumericTraits.h?)

(2) Make any compound type that has a NumericTraits specialization  
include the appropriate itkNumericTraitsXXXPixel.h header. This is  
bad because it causes more headers to be included than potentially  
necessary (what if I just wanted itk::Vector, and don't care about  
the numeric traits for Pixels of that type?), can cause maintenance  
problems (what if a new type is added, but does not include it's  
numeric traits header), *and* makes the meaning of NumericTraits  
slightly different depending on what else has been included.

I'd like to get a fix in the CVS for this, but I'm still rather not  
sure what approach is best -- or least bad.

Zach


On Apr 5, 2006, at 10:02 AM, Kent Williams wrote:

> Solution #1 follows the rules of header parsimony:
> 1. Attempt to only #include headers that are actually relevant to  
> the current source. Maximalist includes slow down compiles, and  
> make tracking down inter-header problems a pain.
>
> 2. If a header is #included, it should have the same behavior  
> regardless of context.  The fact that different traits are defined  
> depending on whether itkNumericTraitsRGB.h is included is a bad thing.
>
> 3. If a header depends on another header, it should include it.  
> This conspires against rule #1, but in ITK, each headers includes a  
> conditional bracket:
>
> #ifndef __itkCLASSNAME_h
> #define __itkCLASSNAME_h
> #endif
>
> So you can optimize out duplicate includes thusly:
>
> #ifndef __itkCLASSNAME_h
> #include <itkCLASSNAME.h>
> #endif
>
> Zachary Pincus wrote:
>
>> (1) Make the above headers #include the correct numeric traits.
>> (2) Make the master NumericTraits header #include all subsidiary   
>> headers. (Brad didn't really like this, but I list it for  
>> completeness.)
>> (3) By convention, every time a user uses a compound pixel type,  
>> they  will have to remember to also #include the correct  
>> NumericTraits, in  case any of the filters they will use need such  
>> traits.
>>
>> Right now the de facto "solution" is 3. I think 1 or 2 is better,  
>> and  it seems that Brad thinks 1 is the way to go.
>>
>> Should I go ahead and add fix (1) to the ITK CVS?
>>
>> Zach
>> _______________________________________________
>> Insight-developers mailing list
>> 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