On 10/18/2013 10:03 AM, Herb Sutter wrote:
> This is a good point.
>
> First, I suspect STL may have been thinking of going even further and, for example, nailing down CHAR_BITS or having int8_t be required to be a typedef for char. :)
>
> As a lesser step, it would be nice if we could at least make the stdint types non-optional. Perhaps this would be possible in the 21st century.

The exact-width types are required to be provided by C11
implementations that have the corresponding integer types.
So I think what's being proposed effectively already
exists in practice, at least in C. Since it's pretty
much impossible for C++ to remove things from C headers,
the typedefs are virtually guaranteed to exist in C++
implementations as well. C++ might just need to adopt
the corresponding language to reflect this. (Flat out
requiring these typedefs to be provided unconditionally
would only have the effect of making implementations
non-conforming that don't have the underlying types
because of the lack of hardware support.)

Martin

>
> As a still lesser step, if then would it not at least be an improvement to make them conditionally supported instead of just optional?
>
> 18.4.1 in the current working draft has:
>
> typedef signed integer type int8_t; // optional
> typedef signed integer type int16_t; // optional
> typedef signed integer type int32_t; // optional
> typedef signed integer type int64_t; // optional
> typedef signed integer type intptr_t; // optional
> typedef unsigned integer type uint8_t; // optional
> typedef unsigned integer type uint16_t; // optional
> typedef unsigned integer type uint32_t; // optional
> typedef unsigned integer type uint64_t; // optional
> typedef unsigned integer type uintptr_t; // optional
>
> Does it really make sense for these to still be optional?
>
> Herb
>
>
>> -----Original Message-----
>> From: gdr_at_[hidden] [mailto:gdr_at_[hidden]] On
>> Behalf Of Gabriel Dos Reis
>> Sent: Friday, October 18, 2013 8:43 AM
>> To: WG21 UB study group
>> Cc: Jeffrey Yasskin; Herb Sutter
>> Subject: Re: [ub] Justification for < not being a total order on pointers?
>>
>> Herb Sutter <hsutter_at_[hidden]> writes:
>>
>> | How about an omnibus EWG proposal for such things? There way still be
>> | important variation in some areas but it does seem like a few could be
>> | nailed down now...?
>>
>> C99 regulates sized integer typed through <stdint.h> (adopted by C++11),
>> but types such as int8_t or uint8_t are still optional and not required.
>> Additionally these sized integer types are required not to have padding bits
>> or trap representations, and use two's complement. Is the proposal that
>> these types be required, as opposed optional like in C?
>>
>> -- Gaby
>>
>> |
>> | Herb
>> | ----------------------------------------------------------------------
>> | ---------
>> | From: Stephan T. Lavavej
>> | Sent: ‎10/‎18/‎2013 12:08 AM
>> | To: Jeffrey Yasskin; WG21 UB study group
>> | Subject: Re: [ub] Justification for < not being a total order on pointers?
>> |
>> | Yep - I intended for less<void> to simply be op< in functor form, with
>> | no additional semantics.
>> |
>> | Separately, I believe that the Core Language should simply recognize
>> | the fact that all machines these days have a flat memory model. (Two's
>> | complement and 8-bit bytes would be nice too.)
>> |
>> | STL
>> |
>> | -----Original Message-----
>> | From: Jeffrey Yasskin [mailto:jyasskin_at_[hidden]]
>> | Sent: Wednesday, October 16, 2013 3:14 PM
>> | To: WG21 UB study group; Stephan T. Lavavej
>> | Subject: Re: [ub] Justification for < not being a total order on pointers?
>> |
>> | On Wed, Oct 16, 2013 at 3:03 PM, Nevin Liber <nevin_at_[hidden]>
>> wrote:
>> | > On 16 October 2013 16:51, Christopher Jefferson
>> | > <chris_at_[hidden]>
>> | > wrote:
>> | >>
>> | >>
>> | >>
>> | >> Oh, I did not realise that. I assume those weasel words are:
>> | >>
>> | >> 20.10.5: 14 For templates greater, less, greater_equal, and
>> | >> less_equal, the specializations for any pointer type yield a total
>> | >> order, even if the built-in operators <, >, <=, >= do not.
>> | >>
>> | >> I did not think that applied for the std::less<void>
>> | >> specialisation, but I can imagine how you could read that it did.
>> | >
>> | >
>> | > Hmmm... I think you are right... although I thought the intention
>> | > was it works for less<void>.
>> |
>> | IIRC, Stephan intentionally left the weasel-words out of
>> | std::less<void>, and we've discussed that choice before and generally
>> | found it reasonable.
>> | _______________________________________________
>> | ub mailing list
>> | ub_at_[hidden]
>> | http://www.open-std.org/mailman/listinfo/ub
>> | _______________________________________________
>> | ub mailing list
>> | ub_at_[hidden]
>> | http://www.open-std.org/mailman/listinfo/ub
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>