Herb Sutter <hsutter_at_[hidden]> writes:

| 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?

My understanding of 'optional' is that the types are conditionally
supported, and a macro in <stdint.h> indicates whether the corresponding
type is supported. So, I suppose you are looking at one of the two
options above.

| 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?

I would be very grateful if EWG (and C liaisons?) claimed ownership of
these issues [ and took them of my yard :-)]

CC:ing -ext.

-- Gaby