为什么64位Windows上的原生长基元的大小只有4个字节?

请问有人会告诉我这是怎么回事,以及如何使之停止? 严重的是,我是疯了还是64位Windows长型只有4个字节? 这有什么意义呢? 我认为原生长度原始大小应该和原生寄存器大小相同。

[32-bit Linux] me@u32:~$ ./sizes32 sizeof(char): 1 sizeof(short): 2 sizeof(int): 4 sizeof(long): 4 sizeof(long long): 8 [64-bit Linux] me@u64:~$ ./sizes64 sizeof(char): 1 sizeof(short): 2 sizeof(int): 4 sizeof(long): 8 sizeof(long long): 8 [32-bit Windows] C:\Users\me\Downloads>sizes32.exe sizeof(char): 1 sizeof(short): 2 sizeof(int): 4 sizeof(long): 4 sizeof(long long): 8 [64-bit Windows] C:\Users\me\Downloads>sizes64.exe sizeof(char): 1 sizeof(short): 2 sizeof(int): 4 sizeof(long): 4 sizeof(long long): 8 

向后兼容!

Windows来自16位平台,其中sizeof(long) == 4 ,并且广泛使用类型如LONGDWORD …,并且改变它会导致大量代码崩溃或无法编译

在第9频道上,Beer28成员写道:“我无法想象类型宽度变化的程序存在太多问题。 我得到了一个很好的笑声,并做了一个笔记写在Win64数据模型的条目。

Win64团队选择了LLP64数据模型,其中所有积分类型保持32位值,只有指针扩展到64位值。 为什么?

除了在该网页上给出的原因外,另一个原因是这样做避免了打破持久性格式。 例如,位图文件的部分头数据由以下结构定义:

 typedef struct tagBITMAPINFOHEADER { DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER; 

如果LONG从32位值扩展到64位值,则64位程序不可能使用此结构来解析位图文件。

为什么Win64团队选择LLP64模型?

必须至少有32位,至少和int一样大,不能long long 。 而已。 期。

你已经有了很多有效的回应。

只是为了记录,这里是C ++标准中的精确定义:

3.9.1 / 2:有五个标准符号整数类型:“signed char”,“short int”,“int”,“long int”和“long long int”。 在这个列表中, 每个类型至少提供了与列表中的前一个相同的存储空间 。 (…)Plain ints具有执行环境的体系结构所建议的自然大小(44)。

最后一句话表明int的大小对应于寄存器。 不幸的是,它并没有讲述宇宙起源的完整故事,它的脚注只是说:“ (44)就是说,足够大以包含INT_MIN和INT_MAX范围内的任何值,正如在标题<climits>定义的那样