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] add_unsigned/remove_unsigned tweaks


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


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