LP64,LLP64和IL32转换

Question

在80年代从16位转换到32位期间,int是16位或32位.使用当前的64位转换命名法,我知道ILP32和LP32机器的传播非常均匀.当时我相信它被理解为int总是遵循任何给定架构的寄存器或指针宽度,并且long将保持32位.

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

这是(LP64)64bit的预期演变吗？
- 这种char <= short <= int <= long关系如何适应这种将整数类型固定到我们留下的每个平台的新方案？
- 这些过渡方案如何与(您选择{l,u}case)WORD/ DWORD在各种平台上使用相关？
- Windows的某些区域仍包含INT16位的表单.Windows会不会发展成LLP64还是为时已晚？
- 为什么int选择这次被抛弃,而不是在32位过渡期间？

Answer 1

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

int:大多数32位长(Linux,Mac和Windows)长:Mac和Linux上64位,Windows上32位长:Mac,Linux和Windows x64上的64位(u)intptr_t:指针的确切长度(32位)在32位,64位64位系统上)

我只在字符串的上下文中使用char而从不使用short,因为它与大多数桌面系统上的int一样长.

WORD和DWORD很难看,应该避免.如果API强制您使用它们,请在处理时将DWORD替换为DWORD_PTR ......好吧,指针.在恕我直言,首先使用(D)WORD是绝对正确的.

我认为Windows永远不会改变它的决定.太麻烦了

为什么留下了int？为什么金星向相反的方向旋转？第一个问题的答案在这里找到(我相信),第二个问题有点复杂;)

@R:显然你从未编写过Windows代码.不仅有传递给Windows API的参数,还有来自回调的传入参数,例如`WndProc`,以及来自API的返回值.将`WndProc`参数不变地传递给`DefaultWndProc`的唯一可靠方法是使它们成为正确的Windows定义类型(`LPARAM`和`WPARAM`).如果您使用任何其他类型,您的代码从Win16转移到Win32,再从Win32转移到Win64. (4认同)
@Billy:我想你错过了下一句话,请不要在我嘴里说话. (3认同)
我自己总是使用 API 类型，但仅在接口边界上，并且仅当从我自己的类型进行的转换非常重要时才使用。如果您稍后需要使用相同的 API 重用值（例如句柄），那么任意转换为您自己的类型将是愚蠢且危险的。 (2认同)