Date: Fri, 31 Mar 2023 13:50:49 +0200
Could you explain, when the promotion would be detrimental?
E.g.: unsigned overflow is defined behaviour (in comparison to signed overflow), but would it be useful, when you cannot predict the bitwidth?
-----Ursprüngliche Nachricht-----
Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Gesendet:Fr 31.03.2023 13:47
Betreff:[std-proposals] uint_nopro_fast32_t : Types in <cstdint> that don‘t promote
An:std-proposals <std-proposals_at_[hidden]>;
CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
I write code for desktop PC's with a 64-Bit x86 CPU, as well as
embedded Linux devices with 32-Bit and 64-Bit ARM processors (arm +
aarch64), as well as Atmel microcontrollers (thumb) and also Texas
Instruments microcontrollers.
When I write a new library, I try to keep these 5 different
architectures in mind, especially the last one which has a 16-Bit byte
(i.e. 16 == CHAR_BIT). Also I keep in mind that in future I might
compile for a system that has a 64-Bit int.
Sometimes I shy away from the integer types in <cstdint>, for example
sometimes I use 'long unsigned' instead of 'uint_fast32_t', because
the latter might promote to a signed integer.
So I wonder would it be good to have another set of integer types that
don't promote? For example:
uint_nopro_least8_t
uint_nopro_least16_t
uint_nopro_least32_t
uint_nopro_least64_t
uint_nopro_fast8_t
uint_nopro_fast16_t
uint_nopro_fast32_t
uint_nopro_fast64_t
On a machine that has a 64-Bit int, the eight types listed above would
all be typdef's for uint64_t. On a machine that has a 32-Bit int,
you'd have:
typedef uint32_t uint_nopro_least8_t;
typedef uint32_t uint_nopro_least16_t;
typedef uint32_t uint_nopro_least32_t;
typedef uint64_t uint_nopro_least64_t;
typedef uint32_t uint_nopro_fast8_t;
typedef uint32_t uint_nopro_fast16_t;
typedef uint32_t uint_nopro_fast32_t;
typedef uint64_t uint_nopro_fast64_t;
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2023-03-31 11:50:51