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.

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]matics.org] 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_google.com]
> | 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_eviloverlord.com>
> 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