[Insight-developers] itkDefaultConvertPixelTraits consistency issues

[Zachary Pincus]

>> Note especially that traits are created for types 'char' and
>> 'unsigned char'. Here's the rub -- some compilers treat 'char' as a
>> synonym for 'signed char' and others treat it as synonymous with
>> 'unsigned char'. I believe that the C++ spec is silent on this point.
>>
>> Anyhow, this means (I think) that for compilers of the latter type,
>> no traits are ever set up for 'signed char' types.
>
> In case of GCC (tested versions 2.95.3, 3.2.3, 3.3.5, 3.4.3 and  
> 4.0.2),
> char is treated as signed char for the purpose of arithmetic
> calculations. However, in the case of template specialization, char,
> signed char and unsigned char are three distinct types. If the
> specialization for signed char is missing, non-specialized template is
> used. This is not the case for short or int types, compiler treats
> short/int and signed short/int as the same type. It will be  
> interesting
> to check how other compilers are behaving (there is a little program
> attached, just compare the behavior with and without (un)signed char
> specialization present).

Thanks for doing this testing. It's interesting to note that GCC on  
PowerPC and ARM platforms (except under OS X) treats char as  
unsigned. (http://www.network-theory.co.uk/docs/gccintro/ 
gccintro_71.html ) I'm not sure if this really represents any ITK  
users... maybe some Yellow Dog Linux folks.

I think that MS VC++ also treats char as signed also, but I don't  
have a windows box.

>
>> I would therefore suggest either adding a traits class for 'signed
>> char' to this file, or changing the ambiguous 'char' trait to 'signed
>> char'.
>
> I'm for adding 'signed char' specializations, with 'char' ones  
> #ifdef-ed
> as needed.

What sort of #ifdef's do you think might be needed? Should there just  
be a 'char' traits that specifies whatever it is that the compiler  
does on that platform, since those are the traits that the IO classes  
will be compiled with?

Zach