This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] ext/type_traits.h


Hi Howard,

I too have needed these utilities. Fwiw I called them:

to_unsigned<T>::type;
and
to_signed<T>::type;

I note that specializations don't exist for signed/unsigned char. It seems like that would be useful as well. But when you do that, then remove_unsigned<unsigned char>::type -> signed char, doesn't seem to fit as well.

Yes, char/signed char/unsigned char seem tricky - I gave the issue a bit of thought - and was curious to learn about other opinions... Currently this is what we have:


 template<typename _Value>
   struct __add_unsigned
   { typedef _Value __type; };

 template<>
   struct __add_unsigned<char>
   { typedef unsigned char __type; };

...

 template<typename _Value>
   struct __remove_unsigned
   { typedef _Value __type; };

 template<>
   struct __remove_unsigned<unsigned char>
   { typedef char __type; };

...

I want to say that whereas, per your citation, I also called the trait to_* when I "invented" ;) it, the new naming scheme may have advantages: we are directing attention to the syntactic notion of adding the ""unsigned qualification"" or removing it, not to the actual signedness of the types at issue in input and output (I hope I'm sufficiently clear). Adding to the above the corresponding 2 primary + 2 specializations for __add_signed appear to lead to a consistent set. Honestly, I'm not sure if that fits well to the related facilities in TR1/C++0x (+ usual issue of harmonizing numeric_limits...).

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]