[Insight-developers] itkDefaultConvertPixelTraits consistency issues

[Peter Cech]

On Fri, Jan 13, 2006 at 14:58:31 -0800, Zachary Pincus wrote:
> Hi again,
> 
> I've got another little problem that I've run into while writing ITK  
> wrappers (which force the compiler to explore lots of otherwise  
> untouched nooks and crannies of ITK). This problem/question likely  
> also relates to elements of the C++ standard in which my knowledge  
> may be limited, so forgive me for any errors.
> 
> Anyhow, the issue is that the file Insight/Code/IO/ 
> itkDefaultConvertPixelTraits.h contains the following block:
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(float)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(double)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(int)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(char)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(short)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(unsigned int)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(unsigned char)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(unsigned short)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(long)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(unsigned long)
>   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(bool)
> 
> 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).

> 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.

Regards,
Peter Cech
-------------- next part --------------
#include <cstdio>


template <typename T>
class A
{
  public:
    static const int type = 0;
};


template <>
class A<char>
{
  public:
    static const int type = 1;
};


template <>
class A<signed char>
{
  public:
    static const int type = 2;
};


template <>
class A<unsigned char>
{
  public:
    static const int type = 3;
};


int main()
{
  char c = 0;
  signed char sc = 0;
  unsigned char uc = 0;
  --c;
  --sc;
  --uc;
  printf("c: %d, sc: %d, uc: %d\n", c, sc, uc);

  printf("%d\n", A<signed char>::type);
}