為什么 64 位 Windows 上的本機 long 原語的大小只有 4 個字節？

Question

有人會告訴我這有什么意義，以及如何讓它停止？ 說真的，我是瘋了還是 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

Answer 1

向后兼容！

Windows 來自一個 16 位平台，其中sizeof(long) == 4並且它在其 API 中廣泛使用了LONG 、 DWORD ... 等自定義類型。 Microsoft 對向后兼容性采取了非常嚴肅的立場（有時甚至修改其代碼以使愚蠢的舊代碼工作）並且更改會產生很多問題

在第 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 模型？

Answer 2

long必須至少為 32 位，至少與int一樣大且不大於long long 。 就是這樣。 時期。

Answer 3

您已經收到了大量有效回復。

只是為了記錄，這里是 C++ 標准中的精確定義：

3.9.1/2：有五種標准的有符號整數類型：“signed char”、“short int”、“int”、“long int”和“long long int”。 在此列表中，每種類型至少提供與列表中它之前的類型一樣多的存儲空間。 (...) 普通整數具有執行環境架構建議的自然大小 (44)。

最后一句暗示 int 的大小與寄存器對應。 不幸的是，它沒有講述宇宙起源的完整故事，它的腳注只是說：“ (44) 也就是說，足夠大以包含 INT_MIN 和 INT_MAX 范圍內的任何值，如標題<climits>所定義”