LP64、LLP64和IL32过渡

Question

在80年代从16位到32位的过渡期间, int 是16或32位。使用当前的64位转换命名法，我知道ILP32和LP32机器的传播相当均匀。当时我相信大家都知道 int 将始终遵循任何给定体系结构的寄存器或指针宽度，并且 long 将保持32位。

快进25年，我看到LP64是相当主流的，但直到我遇到64位平台[我在2007年发现桌面Linux:)]，我一直期望IP64是下一个合乎逻辑的步骤。

1. 这是（LP64）64位的预期演变吗？
   • 如何 char <= short <= int <= long 关系是否适合这种将整数类型固定到我们留下的每个平台的新兴方案？
   • 这些过渡方案如何与使用（您选择的 {l,u}case) WORD/DWORD 在各种平台上？
   • Windows的某些区域仍然包含 INT 是16位的形式。Windows会从LLP64中长出来还是为时已晚？
   • 为什么 int 选择这次被抛在后面，而不是在32位过渡？

Answer 1

我如何看待它是Windows在整个x64过渡中是一个古怪的东西。但抛开这一点，C或C++从未将整数类型定义为固定长度。我发现整个 int/long/pointer 如果你这样看，事情是可以理解的:

• int:主要是32位长（Linux，Mac和Windows）
• long:Mac和Linux上的64位，Windows上的32位
• long long:Mac、Linux和Windows x64上的64位
• (u)intptr_t:指针精确长度（32位上为32，64位系统上为64）

WORD 和 DWORD 是丑陋的，应该避免。如果API强制您使用它们，请替换 DWORD 与 DWORD_PTR 当你在处理的时候。..好吧，指针。这是从来没有正确的使用（D)WORD 首先，恕我直言。

我不认为Windows会改变它的决定，永远。已经麻烦太多了。

为什么 int 留在后面？为什么金星会向相反的方向旋转？找到第一个问题的答案 这里 （我相信），第二个有点复杂;）

Answer 2

而不是把它看作是 int 作为"落在后面"，我会说你应该看看它不能留下任何可能需要的尺寸类型。我想编译器可以定义 int32_t 在一些内部方面 __int32_t 扩展类型，但C99仍然没有得到广泛的支持，这将是一个主要的痛苦，应用程序必须解决丢失 int32_t 当他们的构建系统在标准类型中找不到32位类型时的定义。并且具有32位类型 是 至关重要的是，无论您的本机单词大小如何（例如，它是Unicode代码点值的唯一正确类型）。

出于同样的原因，这将是不可行的 short 32位和 int 64位:16位类型对于许多事情来说都是必不可少的，首先想到的是音频处理。（更不用说Windows的/Java的丑陋UTF-16痴迷。.)

真的，我不认为16到32位和32到64位转换是完全可比的。留下16位是留下一个系统，在这个系统中，日常生活中遇到的大多数数字都不适合基本类型，并且必须使用像"远"指针这样的黑客来处理非平凡的数据集。另一方面，大多数应用程序对64位类型的需求很小。大型货币数字，多媒体文件大小/偏移量，磁盘位置，高端数据库，对大型文件的内存映射访问等。是一些专门的应用程序浮现在脑海中，但没有理由认为文字处理器需要数十亿个字符，或者网页需要数十亿个html元素。数字量与物质世界的现实、人类的思想等之间的关系存在根本性的差异。