[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