为什么在C ++中，我们使用DWORD而不是unsigned int？
我不害怕承认我是一个C ++新手，所以这可能看起来像一个愚蠢的问题，但….
我在代码示例中看到DWORD在各处使用。 当我查找DWORD的真正含义时，它显然只是一个无符号整数（0到4,294,967,295）。 所以我的问题是，为什么我们有DWORD？ 它是什么给我们的整型“unsigned int”不？ 这与便携性和机器差异有关吗？
DWORD不是C ++types，它是在<windows.h>定义的。
原因是DWORD具有Windows函数所依赖的特定范围和格式，因此如果您需要特定范围使用该types。 （或者正如他们所说的：“在罗马时，像罗马人那样做。”）对于你来说，这恰好对应于unsigned int ，但并不总是如此。 为了安全起见，当DWORD被预期时使用DWORD ，而不pipe它实际上是什么。
例如，如果他们更改了unsigned int的范围或格式，则可以使用不同types的DWORD以保持相同的要求，并且所有使用DWORD代码都不是那么明智。 （同样，他们可以决定DWORD需要unsigned long long ，改变它，并且所有使用DWORD代码都不是那么聪明）。
还要注意， unsigned int不一定有0到4,294,967,295的范围。 看到这里 。
当MS-DOS和Windows 3.1以16位模式运行时，英特尔8086字是16位，Microsoft WORD是16位，Microsoft DWORD是32位，典型编译器的无符号整型是16位。
当Windows NT以32位模式运行时，英特尔80386字是32位，Microsoft WORD是16位，Microsoft DWORD是32位，而典型的编译器的无符号整型是32位。 WORD和DWORD这两个名字不再是自描述性的，而是保留了微软程序的function。
当Windows以64位模式运行时，Intel字是64位，Microsoft WORD是16位，Microsoft DWORD是32位，典型的编译器的unsigned int是32位。 名字WORD和DWORD不再是自描述的，AND无符号的int不再符合最less意外的原则，但是它们保留了很多程序的function。
我不认为WORD或DWORD会改变。
SDK开发人员更喜欢使用typedef来定义自己的types。 这允许仅在一个地方改变底层types，而不改变所有的客户端代码。 遵循这个约定是很重要的。 DWORD不太可能被改变，但像DWORD_PTR这样的types在不同的平台上是不同的，比如Win32和x64。 因此，如果某个函数具有DWORD参数，则使用DWORD而不是unsigned int，并且您的代码将在所有将来的Windows头文件中编译。
对于我自己，我会假设unsigned int是特定于平台的。 整数可以是8位，16位，32位甚至64位。
另一方面，DWORD指定了自己的大小，即双字。 Word是16位的，所以在所有平台上DWORD将被称为32位
