c++ - 为什么 Win32 API 中不使用标准数据类型？

Question

我学习 Visual C++ Win32 编程已经有一段时间了。为什么使用 , 等数据类型DWORD而不是, 等WCHAR数据类型？UINTunsigned longcharunsigned int

我必须记住何时使用 WCHAR 而不是 const char *，这真的让我很烦。为什么不首先使用标准数据类型？如果我记住 Win32 等效项并将它们也用于我自己的变量会有帮助吗？

Answer 1

是的，您应该为函数的参数使用正确的数据类型，否则您可能会遇到麻烦。

并且这些类型以它们的方式定义而不是使用int等等char的原因是它int从操作系统的接口中删除了“编译器认为应该调整大小的任何内容”。这是一件非常好的事情，因为如果您使用编译器 A、编译器 B 或编译器 C，它们都将使用相同的类型——只有库接口头文件需要做正确的事情来定义类型。

例如，通过定义非标准类型，很容易int从 16 位更改为 32 位。Windows 的第一个 C/C++ 编译器使用 16 位整数。直到 1990 年代中后期，Windows 才获得 32 位 API，直到那时，您使用int的是 16 位。想象一下，您有一个使用数百个int变量的运行良好的程序，突然之间，您必须将所有这些变量都更改为其他变量……这不是很好，对 - 尤其是其中一些变量不需要更改，因为将某些代码移至 32 位 int 不会产生任何影响，因此更改这些位没有意义。

应该注意的WCHAR是，与const char-不同WCHAR的是“宽字符”，wchar_t可比较的类型也是如此。

因此，基本上，“定义我们自己的类型”是一种保证可以更改底层编译器架构的方法，而无需更改（大部分）源代码。所有进行机器相关编码的大型项目都会做这种事情。

Answer 2

内置类型的大小和其他特性（例如int和）long可能因编译器而异，通常取决于运行代码的系统的底层架构。

例如，在最初实现 Windows 的 16 位系统上，int只有 16 位。在更现代的系统上，int是 32 位。

Microsoft 开始定义类型，DWORD以便它们的大小在其编译器的不同版本或用于编译 Windows 代码的其他编译器的不同版本中保持相同。

这些名称旨在反映 Microsoft 定义的底层系统的概念。ADWORD是一个“双字”（如果我没记错的话，它在 Windows 上是 32 位，即使机器“字”在现代系统上可能是 32 位甚至 64 位）。

使用 中定义的固定宽度类型可能会更好<stdint.h>，例如uint16_t和uint32_t-- 但这些仅由 1999 ISO C 标准引入 C 语言（即使在今天，微软的编译器也不完全支持）。

如果您正在编写与 Win32 API 交互的代码，则绝对应该使用该 API 定义的类型。对于不与 Win32 交互的代码，请使用您喜欢的任何类型，或者您正在使用的接口建议的任何类型。

Answer 3

我认为这是一个历史偶然。

我的理论是，最初的 Windows 开发人员知道标准 C 类型大小取决于编译器，也就是说，一个编译器可能有 16 位整数，而另一个编译器可能有 32 位整数。因此他们决定使用一系列 typedef 使 Window API 在不同编译器之间可移植：DWORD无论您使用什么编译器/架构，它都是一个 32 位无符号整数。当然，现在您将使用uint32_tfrom <stdint.h>，但当时不可用。

然后，通过 UNICODE 的事情，他们得到了TCHARvs. CHARvs.WCHAR的问题，但那是另一回事了。

然后，它失去了控制，你得到typedef void VOID, *PVOID;了完全无稽之谈的美好事物。