[Insight-developers] itkDefaultConvertPixelTraits consistency issues

[Zachary Pincus]

Seeing no objection to adding DefaultConvertPixelTraits  
instantiations for signed char types, I've checked in the following  
CVS change to fix this issue, and closed the bug.

If it breaks the build or something horrific like that, I'll revert.  
However, Peter notes that Strostrup refers to three different char  
types with regard to template instantiation, and GCC agrees with  
this, so there *ought* not to be a problem. If things do break on  
other, flakier compilers, I'll need some help setting up the  
conditional compilation in an ITK-sanctioned manner.

Zach

zpincus% cvs diff itkDefaultConvertPixelTraits.h
Index: itkDefaultConvertPixelTraits.h
===================================================================
RCS file: /cvsroot/Insight/Insight/Code/IO/ 
itkDefaultConvertPixelTraits.h,v
retrieving revision 1.17
diff -r1.17 itkDefaultConvertPixelTraits.h
89a90
 >   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(signed char)
181a183
 >   ITK_DEFAULTCONVERTTRAITS_FIXEDARRAY_TYPE_ALL_MACRO(ArrayType,  
signed char); \


On Jan 16, 2006, at 1:01 PM, Zachary Pincus wrote:

> OK, I filed a bug on this: 2725. I'll fix it in the next day or two  
> barring objections.
>
> Zach
>
> On Jan 14, 2006, at 4:44 PM, Peter Cech wrote:
>
>> On Sat, Jan 14, 2006 at 10:59:47 -0800, Zachary Pincus wrote:
>>>>> 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).
>>
>> Just for the record, GCC on Sparc/Solaris shows the same behavior
>> (the above paragraph is for x86/Linux, but I'm pretty sure that GCC
>> recognizes three distinct char types on all supported platforms).
>>
>>> 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.
>>
>>> From what I found on internet, both GCC and MS VC++ treat 'char' as
>> signed by default, but both have a command line switch to change  
>> it to
>> unsigned.
>>
>>>>> 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?
>>
>> What I meant is that some compilers might treat '(un)signed char' and
>> 'char' as the same type also for template specializations. In that  
>> case,
>> presence of both specializations would likely cause a compiler  
>> error (or
>> at least a warning). In the meantime I found a notice of three
>> distinct char types in Bjarne Stroustrup's C++ Glossary
>> (http://public.research.att.com/~bs/glossary.html), therefore such
>> behavior seems unlikely.
>>
>> Regards,
>> Peter Cech
>> _______________________________________________
>> 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