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,

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.

I see. All in all, I'm coming to think that, whereas __add_signed & co make perfect sense to me *as implementation details* probably the eventual __to_signed and __to_unsigned make much more sense to the users of the library (or elsewhere in the library itself as implementation aids).


In short, if you ask me, I agree with you, I would try to finalize from the C++0x point of view something like __to_signed and __to_unsigned.

Paolo.


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