[Insight-developers] itkDefaultConvertPixelTraits consistency issues

Peter Cech pcech at vision.ee.ethz.ch
Sat Jan 14 19:44:22 EST 2006


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


More information about the Insight-developers mailing list