C++ 小型与全部大写数据类型

Question

为什么在 C++ (MSVS) 中，定义了所有大写的数据类型（并且大多数都是相同的）？

1. 这些完全一样。为什么要定义所有大写版本？

   double 和 typedef double DOUBLE

   char 和 typedef char CHAR

2. bool和BOOL（typedef int BOOL），这里都是小写全大写代表布尔状态，为什么后者用int？

通过这些额外的数据类型获得了哪些额外的能力？

Answer 1

ALLCAPS 类型定义始于 Windows 编程的最初几天（1.0 及之前）。例如，当时还没有 bool 类型这样的东西。 Windows API 和标头是为老式 C 定义的。C++ 在开发时甚至都不存在。

因此，为了帮助更好地记录 API，引入了像 BOOL 这样的编译器宏。即使BOOL 和INT 都是相同底层类型（int）的宏，这让您可以查看函数的类型签名以了解参数或返回值是否打算作为布尔值（定义为“ 0 表示 false，任何非零值表示 true") 或任意整数。

作为另一个例子，考虑LPCSTR。在 16 位 Windows 中，有两种指针：near 指针是 16 位指针，far 指针使用 16 位“段”值和该段的 16 位偏移量。实际内存地址在硬件中计算为( segment << 4 ) + offset。

每种类型的指针都有宏或类型定义。 NPSTR 是 near 指向字符串的指针，LPSTR 是 far 指向字符串的指针。如果是const 字符串，那么C 将被添加到：NPCSTR 或LPCSTR。

您可以在“小”模型（默认使用 near 指针）或“大”模型（默认使用 far 指针）中编译代码。各种NPxxx 和LPxxx“类型”将明确指定指针大小，但您也可以省略L 或N，只使用PSTR 或PCSTR 来声明一个可写或常量指针匹配您当前的编译模式。

大多数 Windows API 函数使用 far 指针，因此您通常会在那里看到 LPxxx 指针。

BOOL 与 INT 并不是两个名称是同一基础类型的同义词的唯一情况。考虑一个例子，你有一个指向单个字符的指针，而不是一个以零结尾的字符串。也有一个名字。您可以使用 PCH 作为指向字符的指针，以将其与指向零终止字符串的 PSTR 区分开来。

即使底层指针类型完全相同，这也有助于记录代码的意图。当然有所有相同的变体：PCCH 用于指向常量字符的指针，NPCH 和 LPCH 用于显式近和远，当然 NPCCH 和 LPCCH 用于近和远指针一个恒定的字符。是的，在这些名称中使用C 来表示“const”和“char”令人困惑！

当 Windows 使用“平面”内存模型迁移到 32 位时，不再有 near 或 far 指针，只有平面 32 位指针用于所有内容。但是所有这些类型名称都被保留下来，以使旧代码可以继续编译，它们都被合并为一个。所以NPSTR、LPSTR、普通PSTR，以及上面提到的所有其他变体都成为相同指针类型的同义词（有或没有const修饰符）。

Unicode 大约在同一时间出现，最不幸的是，UTF-8 还没有被发明出来。因此，Windows 中的 Unicode 支持采用 ANSI 的 8 位字符和 Unicode 的 16 位字符（UCS-2，后来的 UTF-16）的形式。是的，当时人们认为 16 位字符应该对任何人都足够了。世界上怎么可能有超过 65,536 个不同的角色？！ （著名的遗言……）

你可以猜到这里发生了什么。 Windows 应用程序可以在 ANSI 或 Unicode（“宽字符”）模式下编译，这意味着它们的默认字符指针将是 8 位或 16 位。您可以使用上面的所有类型名称，它们将与编译您的应用程序的模式相匹配。几乎所有采用字符串或字符指针的 Windows API 都有 ANSI 和 Unicode 版本，带有 A 或 W 后缀实际的函数名。例如，SetWindowText( HWND hwnd, LPCSTR lpString) 变成了两个函数：SetWindowTextA( HWND hwnd, LPCSTR lpString ) 或 SetWindowTextW( HWND hwnd, LPCWSTR lpString )。而SetWindowText 本身变成了一个宏定义为其中一个或另一个，这取决于你是为 ANSI 还是为 Unicode 编译的。

那时，您可能真的想编写代码，以便可以在 ANSI 或 Unicode 模式下编译它。所以除了宏化的函数名之外，还有一个问题是你的窗口标题是使用"Howdy"还是L"Howdy"。 TEXT() 宏（现在更常见的是 _T()）修复了这个问题。你可以写：

SetWindowText( hwnd, TEXT("Howdy") );

它会根据你的编译模式编译成其中任何一个：

SetWindowTextA( hwnd, "Howdy" );

SetWindowTextW( hwnd, L"Howdy" );

当然，今天大部分内容都没有实际意义。几乎每个人都在 Unicode 模式下编译他们的 Windows 应用程序。这是所有现代版本的 Windows 上的本机模式，API 函数的 ...A 版本是本机 Unicode ...W 版本的垫片/包装器。通过为 Unicode 编译，您可以避免执行所有这些 shim 调用。但是您仍然可以根据需要在 ANSI（或“多字节字符集”）模式下编译您的应用程序，因此所有这些宏仍然存在。

Answer 2

Microsoft 决定在 Windows 代码中为所有这些类型创建宏或类型别名。他们可能会寻求与全大写 WinAPI 类型别名的“一致性”，例如 LPCSTR。

但它有什么真正的好处呢？没有。

BOOL 的情况特别令人头疼。尽管一些老式 C 有这样做的惯例（在实际的 bool 进入该语言之前），但现在它真的只是令人困惑……尤其是在将 WinAPI 与 C++ 一起使用时。

Answer 3

这个惯例可以追溯到 30 多年前的 Windows 操作系统。

70 年代和 80 年代初的当前实践仍然是在各种汇编语言和当时的高级语言、Fortran、Cobol 以及命令行解释器和文件系统默认值中使用全部大写进行编程。一种可能植根于打孔卡编码的习惯可以追溯到更远的地方，可以追溯到 20 世纪初。

当我在 1975 年开始编程时，我们使用的打卡器甚至不支持小写字母 as you can see on the pictures, it did not even have a shift key。

MS/DOS 是用汇编语言编写的，就像 80 年代早期最成功的 PC 软件包，如 Lotus 1-2-3、MS Word 等。C 是贝尔实验室为 Unix 系统发明的，并在在 PC 世界中获得动力的时间很长。

在新兴的微处理器世界中，实际上有 2 个独立的学校：英特尔小端世界，提供所有大写汇编文档和大端摩托罗拉替代品，包括小写汇编、C 和 Unix 操作系统和克隆以及其他奇怪的语言，例如作为 lisp。

Windows 是前者的创意，所有大写类型和修饰符的这种扩散在当时并不难看，它看起来一致且令人放心。 Microsoft 尝试了指针修饰符的各种替代方案：far、_far、__far、FAR，最终完全摆脱了这些，但出于兼容性目的保留了原始的全大写 typedef，导致了愚蠢的妥协，例如 32 位LONG 即使在 64 位系统上。

这个答案并不公正，但重温这些记忆很有趣。

Answer 4

只有 MS 知道。

我能想到的唯一好处是某些类型（例如int）的大小取决于操作系统（请参阅the table here）。这将允许在 64 位操作系统上使用 16 位类型，还有更多 typedefs 或 #defines。该代码将更容易移植到其他操作系统版本。

现在，如果这个“可移植”的东西是真的，那么其余类型将遵循相同的约定，即使它们的大小在所有机器上都是相同的。