爲什麼在Win32 API中不使用標準數據類型？

Question

我一直在學習Visual C++ Win32編程一段時間。 爲什麼使用DWORD,WCHAR,UINT等數據類型代替unsigned long,char,unsigned int等？

我必須記住什麼時候使用WCHAR而不是const char *，這真的讓我煩惱。 爲什麼首先不使用標準數據類型？如果我記住Win32等價物並將它們用於我自己的變量，它會有幫助嗎？

Answer 1

是的，你應該使用正確的數據類型作爲函數的參數，否則你可能會發現自己有麻煩。

而且這些類型的定義會是這樣的，而不是使用int，char等的原因是，它消除了「無論編譯器認爲一個int的大小應爲」從OS的界面。這是一件非常好的事情，因爲如果你使用編譯器A，編譯器B或編譯器C，它們都將使用相同的類型 - 只有庫接口頭文件需要做正確的類型定義。

通過定義非標準類型的類型，例如，很容易將int從16位更改爲32位。 Windows的第一個C/C++編譯器使用16位整數。只是在20世紀90年代中後期，Windows獲得了一個32位的API，並且直到那時，你使用的是16位的int。想象一下，你有一個運行良好的程序，使用幾百個變量，突然之間，你必須將所有這些變量改爲別的東西......不會很好，對 - 尤其是其中的一些變量不需要改變，因爲對於你的一些代碼移動到32位int不會有什麼區別，所以在改變這些位時沒有意義。

應當指出的是，WCHAR是不一樣的const char - WCHAR是「寬字符」所以wchar_t是可比的類型。因此，基本上，「定義我們自己的類型」是一種保證可以更改底層編譯器體系結構而不必更改（大部分）源代碼的方法。所有執行機器相關編碼的大型項目都會這樣做。

Answer 2

內置類型（如int和long）的大小和其他特性可能因編譯器而異，通常取決於運行代碼的系統的基礎體系結構。

例如，在最初實現Windows的16位系統上，int僅爲16位。在更現代的系統上，int是32位。

微軟得到定義類型如DWORD，以便它們的大小在其編譯器的不同版本或用於編譯Windows代碼的其他編譯器中保持不變。

這些名稱旨在反映微軟定義的底層系統的概念。 A DWORD是一個「雙字」（如果我正確地記得，它是Windows上的32位，即使機器「字」在現代系統上可能是32甚至64位）。

它可能是更好的使用<stdint.h>定義的固定寬度的類型，如uint16_t和uint32_t - 但這些都只能由1999年的ISO C標準（微軟的編譯器不完全引入到C語言即使是今天也支持）。

如果您正在編寫與Win32 API交互的代碼，那麼您一定要使用該API定義的類型。對於不與Win32交互的代碼，請使用您喜歡的任何類型，或者您使用的接口提供的任何類型。

Answer 3

我認爲這是一次歷史性事故。

我的理論是，原始的Windows開發人員知道標準C類型的大小取決於編譯器，也就是說，一個編譯器可能有16位整數，另一個編譯器可能有32位整數。所以他們決定使用一系列類型定義讓不同編譯器之間的Window API可移植：無論您使用何種編譯器/體系結構，DWORD都是32位無符號整數。自然，現在您將使用uint32_t從<stdint.h>，但是當時不可用。

然後，與UNICODE的事情，他們得到了TCHAR與CHAR與WCHAR問題，但這是另一回事。

然後，它發展成失控，你得到如此完美的東西typedef void VOID, *PVOID;完全是無稽之談。