Re: [v3] ext/type_traits.h

[Howard Hinnant <hinnant at twcny dot rr dot com>]

On Sep 25, 2006, at 10:13 AM, Paolo Carlini wrote:

> Paolo Carlini wrote:
>
> > ... but isn't __add_signed necessary anyway, from out point of  
> > view? Imean, we would have,
> >
> > template<typename _Value>
> >   struct __add_signed
> >   { typedef _Value __type; };
> >
> > template<>
> >   struct __add_signed<char>
> >   { typedef signed char __type; };
> >
> >   ...
> >
> > template<typename _Value>
> >   struct __remove_signed
> >   { typedef _Value __type; };
> >
> > template<>
> >   struct __remove_signed<signed char>
> >   { typedef char __type; };
> >
> >   ...
>
> Ah, yes, as far as __add_signed and __remove_signed are concerned,  
> the ellipsis can be removed, no additional specializations are  
> needed, AFAICS (well, at some point we'll get compiler support for  
> the traits, then no specializations at all ;)

So __add_signed<unsigned char>::type is unsigned char
So __add_signed<unsigned int>::type is unsigned int

?

In the use cases I've personally been involved with, I had an  
integral type T which could be either signed or unsigned, and I  
needed to get its unsigned counterpart (or signed counterpart).   
Actually the former (unsigned counterpart) was my more common need.   
Having to spell that typename __add_unsigned<typename  
__remove_signed<T>::type>::type seems cumbersome.

Are there use cases for __add_signed, as opposed to __to_signed?  If  
all it operates on is char (non-identity operation) I'm having  
trouble coming up motivation for its existence.

-Howard