incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r667365 [1/3] - in /stdcxx/branches/4.3.x: etc/config/src/ include/ include/rw/ tests/utilities/
Date Mon, 23 Jun 2008 16:13:59 GMT
Travis Vitek wrote:
>  
> 
> Martin Sebor wrote:
> 
>> Are you sure the traits are correct for char and wchar_t?
> 
> No.
> 
>> Also, do you believe the working draft to be
>> unambiguous and correct?
> 
> No. For reference, I've pulled the requirements from the standard and
> pasted them below.
> 
> There is at least one obvious ambiguity. Assume that char is signed.
> Should std::make_signed<unsigned char>::type be 'char' or 'signed char'?

Yes. This needs to be clarified. Could you bring it up on
c++std-lib@accu.org to make sure it's not a known problem
that's already being handled? I'll help you write up the
issue if it isn't.

> Same goes for std::make_signed<enum_t>::type when sizeof(enum_t) ==
> sizeof(char). If both 'char' and 'signed char' are signed integral
> types, which of the two should be used?

I didn't think enums could be smaller than int but that's
probably going to change with scoped enums.

> 
> It also seems wrong to have std::make_signed<char>::type be 'signed
> char' only when 'char' is unsigned. It seems that users would like to be
> able to expect that the resulting type be consistent regardless of the
> signed-ness of char.

Sounds like a valid point to me. OTOH, the actual type may
not matter all that much just as long as the signedness is
right. In my experience, in the handful of cases when I've
ever needed an unsigned form of a (possibly) signed type
all I cared about was the absence of signedness.

> 
> Both of these issues make me think that the definition of make_signed
> should have said 'signed integer type' instead of 'signed integral
> type'.

You mean just signed/unsigned integers (I had to look up the
difference). I suspect most people would find a make_signed
that didn't work with char to be broken.

> 
>> Based on my reading, make_signed<T>
>> ::type should be the same as T if T is a signed integral type.
>> IIUC, our make_signed<char>::type is defined to signed char
>> regardless of the signed-ness of char. Ditto for wchar_t.

Right. That's what caught my attention because it goes
against the requirement.

Martin

>>
> 
> [basic.fundamental] p2
> 
>   There are five standard signed integer types: "signed char",
>   "short int", "int", "long int", and "long long int". In this
>   list, each type provides at least as much storage as those
>   preceding it in the list. [...] The standard and extended
>   signed integer types are collectively called signed integer
>   types.
> 
> [basic.fundamental] p3
> 
>   For each of the standard signed integer types, there exists
>   a corresponding standard unsigned integer type: "unsigned
>   char", "unsigned short int", "unsigned int", "unsigned long
>   int", and "unsigned long long int", each of which occupies
>   the same amount of storage and has the same alignment
>   requirements as the corresponding signed integer type. [...]
>   The standard and extended unsigned integer types are
>   collectively called unsigned integer types.
> 
> [basic.fundamental] p7
> 
>   Types bool, char, char16_t, char32_t, wchar_t, and the signed
>   and unsigned integer types are collectively called integral
>   types.
> 
> [meta.trans.sign]
> 
>   If T names a (possibly cv-qualified) signed integral type then
>   the member typedef type shall name the type T; otherwise, if T
>   names a (possibly cv-qualified) unsigned integral type then type
>   shall name the corresponding signed integral type, with the same
>   cv-qualifiers as T; otherwise, type shall name the signed
>   integral type with smallest rank for which sizeof(T) ==
>   sizeof(type), with the same cv-qualifiers as T.
> 
> 


Mime
View raw message