在 80 年代从 16 位到 32 位的过渡期间，int 要么是 16 位，要么是 32 位。使用当前的 64 位转换命名法，我知道 ILP32 和 LP32 机器的分布非常均匀。当时我相信大家理解 int 将始终遵循任何给定架构的寄存器或指针宽度，而 long 将保持 32 位。
快进 25 年，我发现 LP64 相当主流，但直到我遇到 64 位平台 [我在 2007 年发现桌面 Linux :)]，我一直期望 IP64 成为下一个合乎逻辑的步骤。
- 这 (LP64) 是 64 位的预期演变吗？
char≤short≤int≤long关系如何适应这个新兴的修复方案我们留下的每个平台的整数类型？- 这些转换方案如何与(您选择的
{l,u}case)WORD/DWORD的使用相关平台？ - Windows 的某些区域仍然包含 16 位的
INT形式。 Windows 会脱离 LLP64 还是为时已晚？ - 为什么这次选择将
int留在后面，而不是在 32 位转换期间？
最佳答案
在我看来，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 被遗忘？为什么金星自转方向相反？找到第一个问题的答案here (我相信)，第二个有点复杂；)
关于c - LP64、LLP64 和 IL32 转换，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3325706/