在 64 位数据模型上指定 64 位无符号整数文字答案

【问题标题】：Specifying 64-bit unsigned integer literals on 64-bit data models在 64 位数据模型上指定 64 位无符号整数文字
【发布时间】：2012-10-20 22:39:23
【问题描述】：

由于有多种类型的 64 位数据模型（LLP64/IL32P64、LP64/I32LP64、ILP64、SILP64），指定 64 位无符号整数文字的标准符合方式是什么？

指定 ULL 的后缀就足够了吗？还是我最终会导致文字在某些数据模型上被解释为 128 位？

【问题讨论】：

把整数赋值给uint64_t应该没问题。
@KennyTM：最多只能达到 2^32 - 1，此时您可能会遇到麻烦...
@DevSolar：我的意思是带有 ULL 后缀的整数，它肯定适用于高达 18446744073709551615 的值。
@KennyTM：啊……当然。
如果你的文字被解释为 128 位会有问题吗？

标签： c++ integer 64-bit

【解决方案1】：

你应该使用@987654321@，如果你有的话。这会给你：

uint64_t 是一个无符号整数类型，大小为 64 位
UINT64_C() 是一个宏，用于创建uint64_t 类型的常量，方法是让宏附加适当的后缀。

【讨论】：

是否保证 UINT64_C 在 C++ 中可用？（问题是关于 C++，而不是 C99）
@jalf 好点，谢谢！我不确定，但似乎是。我重写并更改了链接。
在很长一段时间后回到这个问题......并且......让我挑剔UNIT64_C解析为uint_least64_t，而不是uint64_t。 ;-)

【解决方案2】：

据我所知，没有办法将整数文字添加到特定位宽的后缀；您唯一的选择是 l、ul、ll 和 ull。

如果您对此持怀疑态度，则必须将文字包装在 #if 中，检查 long / long long 的大小。

然后，正如 KennyTM 上面指出的那样，只要您的文字在 64 位范围内分配给 64 位值，如果文字本身是 64 位还是 128 位，或者是吗？

【讨论】：

这不会导致编译器抱怨我将需要较大位宽的整数分配给较小的整数（截断警告）？
使用大写后缀来保持带符号的文字可读性：1L, 1LL 而不是 1l, 1ll。

【解决方案3】：

在大多数情况下，这并不重要。如果你不给它一个后缀，一个整数文字的类型是由它的值决定的。如果编译器具有 32 位 unsigned long 和 64 位 unsigned long long，则对于 unsigned long 而言太大而无法容纳但对于 unsigned long long 而言又不会太大的无符号值将具有类型 unsigned long long。

【讨论】：

【解决方案4】：

C 和 C++ 没有标准化的 32/64/128 位变量类型。例如，long 在某些系统上是 32 位，而在其他系统上是 64 位。这很烦人，但大多数操作系统确实提供了一些更好的 typedef 来帮助您，例如 uint32 等，因此您可以选择您需要的确切类型。

这是一个优秀的configure 脚本的工作：确定系统提供的内容，测试它的工作原理，并帮助您为正在运行的正确架构选择正确的类型。

【讨论】：

C 和 C++ do 在 <stdint.h> 和 <cstdint> 标头中提供给定大小的标准化变量类型。他们的名字如uint32_t。
@amaurea - 诸如uint32_t 之类的名称在没有这些精确大小的系统上不可用。在几乎所有情况下，uint_least32_t 等都是更好的选择。
@Pete Becker 没有uint32_t 和uint64_t 的系统几乎是不可能找到的，不是吗，它们与字节不是8 位长的系统和其他好奇心属于同一类别？
@amaurea - 在你找到它们之前是不可能找到的，然后你必须在你的代码中找到所有不合理的假设并修复它们。有很多系统没有 8 位字节；它们不是好奇心，而是真实世界的系统。 DSP 就是一个典型的例子。
... 但它没有回答问题。 :) 无论uint64_t 是否存在，它都对想要编写 64 位整数文字的人没有帮助