uint32， int16， uint8 .为什么这些常用的数据类型没有进入标准

uint32, int16, uint8 .. Why these commonly used data types are not making it into the standards

本文关键字：数据类型 标准 常用 uint8 int16 为什么 uint32      更新时间：2023-10-16

多年来，在涉及C/C++的多个组织和各种项目中，我已经看到通过定义types.h的本地版本解决了对固定宽度整数的需求，该版本通常如下所示：

typedef  signed char        int8;
typedef  unsigned char      uint8;
typedef  signed short       int16;
typedef  unsigned short     uint16;
typedef  signed long        int32;
typedef  unsigned long      uint32
typedef  signed long long   int64;
typedef  unsigned long long uint64;

为什么这些没有集成到 C/C++ 标准中？

我知道C99已经标准化了uint32_t之类的东西。同样，Microsoft也定义了自己的UINT32等。- 但这些仍然需要typedefs，因为 uintX 术语的使用在经验丰富的开发人员编写的遗留代码和新代码中很普遍

我也知道 Boost 整数库 - 同样，这不是标准C++因为他们清楚地提到：-

因为这些是提升标头，所以它们的名称符合提升标头 命名约定而不是C++标准库标头命名 约定。

关于将[u]intX集成到官方标准的利弊的想法？

编辑：
这个问题已经产生了高质量的答案和意见。谢谢他们信息丰富且乐于助人！一些评论表明这个问题还不够清楚：">
您专门询问为标准中已经存在的 typedef 添加更多别名">- 是的，正是

@Pascal Cuoq的ans解决了真正的问题，以防这些被添加到标准中：-

不要等待名称uint32成为正式名称 C++中的整数类型;它可能永远不会发生，正是因为 如此多的程序已经将类型定义为此名称。

C99 引入了标头stdint.h(7.18)，C++11 将其作为<cstdint>导入。

您可能会问为什么其中的类型名称是uint32_t而不是uint32。很简单：因为这样名称就会与现有代码冲突。

POSIX为类型保留了_t后缀。(如果你想与当前和未来的POSIX系统兼容，你不应该在你的程序中对任何类型的_t使用。这是即使是有经验的程序员也会犯的常见错误)。POSIX 还使用其保留的命名空间以uint32_t格式安全地定义类型名称。

C99选择了与POSIX相同的名称。从C委员会的角度来看，这些名称不太可能破坏现有的程序(在发展C语言时，向后兼容性是一个非常重要的考虑因素)。后来，当它们出现在C++中时，保持C++和C之间的兼容性比选择不同的名称更有价值。

不要等到uint32这个名字成为整数C++类型的正式名称;它可能永远不会发生，正是因为很多程序已经在typedef一个类型到这个名字。

实际上它们是C++ 11 标准的一部分，但带有_t后缀：

http://en.cppreference.com/w/cpp/types/integer

不偏离其他常见类型并坚持命名方案。如果一些标准类型以_t结尾，而有些则不以 结尾，这将是非常违反直觉的。

但其中一些是可选的，因为底层硬件可能不支持它们。因此有一些对应物，如int_least8_t，其大小至少为 8 位：

宽度至少为 8 位的最小有符号整数类型

这种类型反过来又可以保证便携性。

你不能/不应该把东西放在一个不可移植的标准上，这将不允许在特定平台上使用该语言。

有多少代码中断？除了上面的思想之外，我还从以前的C++标准委员会会议上读到的内容：当要引入新功能时，会进行参考实现，并对现有代码运行编译测试，以了解此功能可能会破坏多少代码。例如，更改auto关键字含义时就是这种情况。

自 90 年代后期以来，带有_t后缀的 typedef 一直作为不同官方标准的一部分存在，可能更早，这就是为什么那些版本被纳入 C 和 C++ 标准的原因。

当标准类型定义已经存在时，人们使用不同的类型定义是他们的问题。在标准中复制整个 typedef 列表只会造成更大的混乱。

相关文章：