long和int的历史背景通常是相同的大小？
根据这里的众多答案 ， long和int在C和C ++（Windows和Linux，32和64位）的通用平台上都是32位大小（我知道没有标准，但实际上，这些都是观察到的尺寸。）
所以我的问题是，这是怎么发生的？ 为什么我们有两种尺寸相同的类型？ 我以前总是假设大部分时间都是64位，而且是32位。我不是说“应该”是这样或那样的，我只是好奇我们是如何到达这里的。
从6.2.5节的C99原理（PDF） ：
[…]在20世纪70年代，16位C（用于PDP-11）首先用16位整数表示文件信息，这些整数很快就被磁盘进展所淘汰。 人们切换到32位文件系统，首先使用
int[2]结构，这些结构不仅笨拙，而且无法有效地移植到32位硬件。为了解决这个问题，将
long类型添加到语言中，即使这需要PDP-11上的C生成多个操作来模拟32位算术。 即使32位小型计算机与16位系统一起使用，人们仍然使用int来提高效率，在真正需要更大整数的情况下保留long，因为16位系统的效率显着降低。short和long都加到了C中，short可用16位，long32位，而int方便性能。 不希望将数字16或32锁定到语言中，因为存在至少24位和36位CPU的C编译器，而是根据需要提供可用于32位的名称。PDP-11 C可能已经使用
int重新实现为32位，从而避免了需要long; 但这会让人们改变大多数int用途，或者在PDP-11上遭受严重的性能下降。 除了对源代码的潜在影响之外，即使在1976年，对现有目标代码和数据文件的影响也会更糟。到了20世纪90年代，由于安装了大量软件，并且广泛使用动态链接库，在现有环境中更改公共数据对象大小的影响是如此之高，以至于很少有人会容忍它，尽管在创建新环境时可能会接受。 因此，为避免名称空间冲突，许多供应商使用新名称在其32位C环境中添加了64位整数，其long long使用最为广泛。 […]
从历史上看，C中的大多数尺寸和类型都可以追溯到PDP-11架构。 它有字节，字（16位）和双字（32位）。 当C和UNIX被移动到另一台机器（我认为是Interdata 832）时，字长为32位。 为了保持源兼容，严格定义long和int
sizeof(short)sizeof(int)sizeof(long)。
现在大多数机器都以sizeof(int) = sizeof(long)因为16位不再方便，但如果需要，我们很长时间可以获得64位。
严格更新我应该说“编译器”，因为不同的编译器implmentors可以为相同的指令集架构做出不同的决定。 例如，海湾合作委员会和微软。
早在70年代末和80年代早期，许多架构都是16位，所以通常char为8位，int为16位，长为32位。 在80年代后期，通常采用32位架构，因此int变为32位，但长期保持在32位。
在过去的10年里，我们已经向64位计算迈进了一步，我们现在有了几种不同的模型，最常见的是LP64 ，其中整数仍为32位，长整数为64位。
结论：不要对不同整数类型的大小做任何假设（当然，除了标准中定义的大小），如果需要固定大小类型，则使用
据我了解，C标准要求long至少32位，并且至少与int一样长。 另一方面， int总是（我认为）等于架构的本机字大小。
请记住，在制定标准时，32位机器并不常见; 最初，一个int可能是本机的16位，而long则是32位的两倍。
在16位操作系统中，int为16位，long为32位。 移动到Win32后，两者都变为32位。 转移到64位操作系统，保持长大小不变是一个好主意，这在64位编译时不会破坏现有代码。 新类型（如Microsoft特定的__int64，size_t等）可用于64位程序。