intmax_t 和 uintmax_t 是否保证大小相同？

Question

我需要知道intmax_t是否总是与uintmax_t “相同类型”，除了使用补码而不是无符号值。

或者用正式的术语来说，下面的代码是否总是在符合标准的编译器中编译？

#include <cstdint>

// The important assertion:
static_assert(sizeof(std::uintmax_t) == sizeof(std::intmax_t));
// Less important assertions:
static_assert(UINTMAX_MAX == static_cast<std::uintmax_t>(INTMAX_MAX) * 2 + 1);
static_assert(-static_cast<std::intmax_t>(UINTMAX_MAX / 2) - 1 == INTMAX_MIN);

我对 C++17 特别感兴趣。

我知道 C++20 是第一个强制执行二进制补码的标准版本，但变量的大小对我来说比表示形式更重要。

Answer 1

是的， uintmax_t保证是intmax_t的无符号副本。

来自 C 标准（N1570 7.20.1）：

当定义的 typedef 名称仅在缺少或存在初始u时不同，它们应表示相应的有符号和无符号类型，如 6.2.5 中所述； 提供这些相应类型之一的实现也应提供另一个。

（C++对C标准库头文件的描述，简单参考C。）

6.2.5 第 6 页：

对于每个带符号的 integer 类型，都有一个对应的（但不同的）无符号 integer 类型（用关键字unsigned指定），它使用相同的存储量（包括符号信息）并且具有相同的 alignment 要求。

C++ 在这方面类似于 C ( [basic.fundamental]/3 )：

对于每个标准签名 integer 类型，存在一个对应的（但不同的）标准无符号 integer 类型 [...] 也就是说，每个带符号的 integer 类型与其对应的无符号 integer 类型具有相同的 object 表示。 同样，对于每个扩展的有符号 integer 类型，都存在一个相应的扩展无符号 integer 类型，具有相同的存储量和 alignment 要求。

这意味着intmax_t和uintmax_t总是具有相同的大小。

但是，不能保证其他两个断言会成立（在 C++20/C23 之前）。

Answer 2

从评论/标题来看，您似乎在问是否需要相同的尺寸； 在这种情况下，简短的回答是肯定的......长答案......有点:)

引自[basic.fundamental]/3 （C++17 草案 N4713）

对于每个标准的有符号 integer 类型，存在一个对应的（但不同的）标准无符号 integer 类型：“unsigned char”、“unsigned short int”、“unsigned int”、“unsigned long int”和“unsigned long long int” ”，每个都占用相同的存储量，并且与其对应的签名 integer 类型具有相同的 alignment 要求。

（强调我的）

这保证了未签名的版本占用与其签名的等效版本相同的大小。

话虽这么说，标准[cstdint.syn]只说明：

使用 intmax_t = signed integer 类型；

使用 uintmax_t = unsigned integer 类型；

[basic.fundamental]/2状态

标准和扩展签名 integer 类型统称为签名 integer 类型。

和[basic.fundamental]/3状态

标准和扩展的unsigned integer类型统称为unsigned integer类型

因此，从技术上讲，编译器不必将它们实现为相同的类型，因为那是一个实现细节； 但实际上，它们是一样的。

---

正如鸭子所指出的，C 标准确实表明在带有u和没有u前缀的类型之间必须有对应的版本。 C 标准通过[cstdint.syn]/2引用

Answer 3

我的回答被鸭子证明是不正确的。 谢谢鸭！

https://stackoverflow.com/a/75203111/2027196

我的原始答案以备将来参考：

标准不保证uintmax_t和intmax_t具有相同的宽度，但是不存在具有现代 C 编译器的系统，它们将具有不同的宽度。 甚至可能没有非现代的 C 编译器，它们将具有不同的宽度（在没有证据的情况下断言与“天空是蓝色的”类型 arguments 相同）。

你能得到的最好的是uintmax_t和intmax_t按照约定保证宽度相同。 我说“你能得到的最好的”，但我更愿意依赖这种保证，而不是依赖编译器完美地实现其所有边缘情况 SFINAE 要求或类似要求。

将static_assert放在库的顶部（可能在assumptions.hpp文件中），然后再也不用担心这个问题了。