Re: [boost] More type_traits confusion

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-01-21 21:13:41

----- Original Message -----
From: "Howard Hinnant" <hinnant_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, January 21, 2001 8:31 PM
Subject: Re: [boost] More type_traits confusion

> David Abrahams wrote on 1/21/2001 7:55 PM
> >Now I've been using is_signed_integral<T> to find out whether a
> >compiler-supplied type is signed or not, and I've been getting away with
it,
> >but it turns out you can't even do that.
> >is_standard_signed_integral<T> isn't specialized for char. I (now)
> >understand the logic behind it, since the standard doesn't specify
whether
> >char is signed or unsigned, but then why do all my uses of
> >is_signed_integral<char> seem to compile without complaint?
> >
> >I think we have to get a lot clearer about the intent of type_traits in
its
> >documentation.
>
> Instead of the current is_signed_XXX structs I prefer a simpler struct
> that cuts across all XXX:
>
> template <class T> struct is_signed
> {static const bool value = T(-1) < T(0);};
>
> template <class T> struct is_unsigned
> {static const bool value = !is_signed<T>::value;};
>
> Requires that T is constructable from the literals -1 and 0.
> Compile-time results if that requirement is not met (and thus signedness
> is not likely to have meaning for that type).

Yes, I have reverted to using something like that.

> Note that is_signed<char>::value is both well formed and well-defined,
> though its result will vary with implementations.

I think you should look again. For CW and GCC, is_signed<char>::value
reports false, even though chars are signed.

-Dave