[v3] ext/type_traits.h

Howard Hinnant hinnant@twcny.rr.com
Mon Sep 25 14:35:00 GMT 2006


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



More information about the Libstdc++ mailing list