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

[Karthik Krishnan]

Zach,

Please replace line 20 in itkRGBPixel.h with
#include "itkNumericTraitsRGBPixel.h"

and let us know if that fixes your wrapping issue.



Nobody should in general need to include NumericTraits.h. They should 
only need to include the header file for the pixel type. ie #include 
"Pixel.h". IMHO this is how things should look.

For instance:

Pixel.h :
   class Pixel{ ... };

Pixel.txx
  #include "NumericTraitsPixel.h"
  #include "Pixel.h"
  
NumericTraitsPixel.h
  #include "Pixel.h"
  template <> NumericTraits< Pixel > { ... }


IMHO that should how things should look. This is not what RGBPixel.h/txx 
does and I think that's the bug. All the other pixels (for instance 
VariableLengthVector.h/txx do this). I did not have issues wrapping this 
class or classes that used this class.


Please correct me if I am wrong.

-karthik
  

Zachary Pincus wrote:

> 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
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>