This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] add_unsigned/remove_unsigned tweaks
- From: Howard Hinnant <hhinnant at apple dot com>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 29 Sep 2006 11:21:42 -0400
- Subject: Re: [v3] add_unsigned/remove_unsigned tweaks
- References: <20060929142819.c530c422.bkoz@redhat.com>
On Sep 29, 2006, at 8:28 AM, Benjamin Kosnik wrote:
Adds in signed char bits as discussed by Paolo and Howard, and tests.
In addition, this adds compile-time warnings on things like
__gnu_cxx::__remove_unsigned<float>::__type
__gnu_cxx::__add_unsigned<bool>::__type
Even though these constructs are admittedly bizarre, it looks like
this "trait" is
converging on semantic meaning, and signed-ness means nothing for
floating point types. (Last time I checked.)
tested x86/linux
Clever use of enable_if in the primary.
Do we think that having both std::tr1::is_integral<T>::value (now in
the WP as std::is_integral<T>::value), and
std::__is_integer<T>::__value *and* having them mean two different
things is error prone or confusing?
#include <tr1/type_traits>
#include <iostream>
int main()
{
std::cout << std::tr1::is_integral<const int>::value << '\n';
std::cout << std::__is_integer<const int>::__value << '\n';
}
I'm asking because __add_unsigned builds on __is_integer and impacts
how we handle __add_unsigned with cv-qualified integral types.
-Howard