uint_fast32_t是否保证至少与int一样宽? [英] Is `uint_fast32_t` guaranteed to be at least as wide as `int`?

问题描述

C标准规定，小于int的整数操作数将在对其执行任何算术运算之前提升为int.结果，将对两个小于int的无符号值进行运算，而不是使用无符号数学运算.如果必须确保对32位操作数的运算将使用无符号数学运算(例如，将两个乘积的乘积可能超过2×3的数字相乘)，将由任何标准保证使用uint_fast32_t类型的值来产生无符号语义，而无需任何未定义的行为?如果不是，是否有其他无符号类型可以保证至少为32位且至少与int一样大?

The C standard specifies that integer operands smaller than int will be promoted to int before any arithmetic operations are performed upon them. As a consequence, operations upon two unsigned values which are smaller than int will be performed with signed rather than unsigned math. In cases where it is important to ensure that operation on 32-bit operands will be performed using unsigned math (e.g. multiplying two numbers whose product could exceed 2⁶³) will use of the type uint_fast32_t be guaranteed by any standard to yield unsigned semantics without any Undefined Behavior? If not, is there any other unsigned type which is guaranteed to be at least 32 bits and at least as large as int?

推荐答案

不，不是.无论如何，我建议不要使用[u]int_fastN_t类型.在现实世界的系统上，它们的定义是错误的.例如，uint_fast32_t通常在x86_64上被定义为64位类型，尽管64位操作的最佳速度(加法，减法，逻辑运算)与32位的速度相同，但最坏​​的情况是慢得多(划分和加载/存储，因为您使用的缓存行数是原来的两倍).

No, it's not. In any case, I would advise against using the [u]int_fastN_t types at all. On real-world systems they're misdefined; for example, uint_fast32_t is usually defined as a 64-bit type on x86_64, despite 64-bit operations being at best (addition, subtraction, logical ops) identical speed to 32-bit ones and at worst much slower (division, and loads/stores since you use twice as many cache lines).

这篇关于uint_fast32_t是否保证至少与int一样宽?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！