许多编译器提供 128 位整数类型,但我使用的没有一个提供 typedefs int128_t
。为什么?
据我记得,标准
int128_t
为此目的的储备金- 鼓励提供此类类型的实现提供 typedef
- 要求此类实现提供
intmax_t
至少 128 位的
(而且,我不相信我使用的实现实际上符合最后一点)
许多编译器提供 128 位整数类型,但我使用的没有一个提供 typedefs int128_t
。为什么?
据我记得,标准
int128_t
为此目的的储备金intmax_t
至少 128 位的(而且,我不相信我使用的实现实际上符合最后一点)
我会参考C标准;我认为 C++ 标准从 C继承了<stdint.h>
/的规则。<cstdint>
我知道 gcc 在某些平台上实现了 128 位有符号和无符号整数,其名称为__int128
and unsigned __int128
(__int128
是实现定义的关键字)。
即使对于提供标准 128 位类型的实现,该标准也不需要 int128_t
也不需要uint128_t
定义。引用C 标准N1570草案的第 7.20.1.1 节:
这些类型是可选的。但是,如果实现提供了宽度为 8、16、32 或 64 位的整数类型,没有填充位,并且(对于有符号类型)具有二进制补码表示,则它应定义相应的 typedef 名称。
C 允许实现定义扩展整数类型,其名称是实现定义的关键字。gcc__int128
和unsigned __int128
标准定义的扩展整数类型非常相似——但 gcc 不会那样对待它们。相反,它将它们视为语言扩展。
特别是,如果__int128
和unsigned __int128
是扩展整数类型,则需要 gcc 将intmax_t
和定义uintmax_t
为这些类型(或某些类型至少 128 位宽)。它不这样做;相反,intmax_t
并且uintmax_t
只有 64 位。
在我看来,这很不幸,但我不相信它会使 gcc 不合格。任何可移植程序都不能依赖 的存在__int128
,或者任何大于 64 位的整数类型。intmax_t
并且更改uintmax_t
会导致严重的 ABI 兼容性问题。