C程序中整数的历史typedef汤是怎么回事？

Question

这可能是一个毫无意义的问题，我应该知道它的答案。

大约15年前，我看到的许多C代码在特定于平台的#ifdefs中有大量整数typedef。似乎我看到的每个程序或库都有自己的、相互不兼容的typedef汤。当时我对编程知之甚少，为了告诉编译器你想使用什么样的整数，我似乎要跳过一大堆奇怪的障碍。

我在脑海中编了一个故事来解释那些typedef是关于什么的，但我不知道这是否是真的。我的猜测基本上是，当C最初被开发和标准化时，它没有意识到能够在平台上独立地获得一个特定大小的整数类型有多么重要，因此所有原始的C整数类型可能在不同的平台上具有不同的大小。因此，每个试图编写可移植C代码的人都必须自己编写。

这是正确的吗？如果是这样，程序员应该如何使用C整数类型？我的意思是，在一个有很多位旋转的低级语言中，能说“这是一个32位整数”不是很重要吗？自从1989年该语言被标准化以来，肯定有人认为人们会试图编写可移植代码？

Answer 1

我记得那段时间，我也犯了同样的错误！

一个问题是int的大小，它可能与short相同，也可能与long相同，或者介于两者之间。例如，如果您使用的是二进制文件格式，那么所有内容都必须对齐。字节排序也很复杂。许多开发人员走的是懒散的路线，只是写了一些东西，而不是一个字节一个字节地把数字分开。当机器升级到更长的字长时，所有的麻烦都爆发了。所以typedef是一个很容易解决的问题。

如果性能是一个问题，就像当时经常发生的那样，int肯定是机器最快的自然大小，但是如果你需要32位，而int比这更短，你就有翻车的危险。

在C语言中，sizeof（）不应该在预处理器阶段解析，这使得事情变得复杂，因为如果sizeof（int）==4，您就不能执行#。

就个人而言，一些基本原理也只是从汇编语言的心态出发，不愿意抽象出什么短，int和long的概念。那时，汇编程序在C语言中使用得非常频繁。

现在，有很多非二进制文件格式，如JSON、XML等，其中二进制表示形式是什么并不重要。此外，许多流行的平台都采用了32位int或更长的格式，这对于大多数目的来说已经足够了，因此滚动问题就少了。

Answer 2

C早期的成功是由于它灵活地适应了几乎所有现有的变体html" target="_blank">架构@John Hascall：
1）8, 16, 18, 24, 32, 36等比特的本地整数大小，
2）变体有符号整数模型： 2的补码，1的补码，有符号整数和
3）各种尾数，大，小和其他。

随着编码的发展，算法和数据交换推动了更大的一致性，因此需要满足1

c99引入了（u）int_leastN_t，（u）int_fastN_t，（u）intmax_t，使其具有可移植性，但有些是最小位宽类型。N=8,16,32,64需要这些类型。

此外，还引入了半可选类型（见下文**），如（u）intN\u t，该类型具有以下附加属性：它们必须是2的补码，并且没有填充。正是这些广受欢迎的类型被广泛期望，并用于稀释整数汤。

程序员应该如何使用C整数类型？

通过编写不强烈依赖于位宽度的灵活代码。只使用LONG\u MIN，LONG\u MAX编码strtol（）非常容易，而不考虑位宽/endian/整数编码。

然而，许多编码任务要求精确的宽度类型和2的补充，以便于高性能编码。在这种情况下，最好放弃对36位机器和32位符号大小机器的可移植性，坚持使用2^N宽（有符号的2补码）整数。各种CRC

今天，仍然有一些难题需要处理。例如：通常的促销int/un符号失去了一些控制，因为这些类型可能是16、32或64。

**

这些类型是可选的。但是，如果一个实现提供了宽度为8、16、32或64位的整数类型，没有填充位，并且（对于有符号类型）具有2的补码表示，它应该定义相应的typedef名称。C117.20.1.1精确宽度整数类型3

Answer 3

当C开始的时候，计算机没有今天那么同质，连接也少了很多。对于可移植性来说，int类型被认为是计算机的自然大小更为重要。在36位系统上要求精确的32位整数类型可能会导致代码效率低下。

然后出现了普及的网络，在这里，您可以在特定的导线尺寸字段上进行工作。现在互操作性看起来完全不同了。而“八位元”成为数据类型的事实量子。

现在你需要8位整数的精确倍数，所以现在你得到typedef-soup，然后最终标准迎头赶上，我们有了它们的标准名称，而soup不是需要的。