C 重新创建Win32'是个好主意吗；s标题？

最近，我发现自己在Win32上编写了更多的C/C++代码，并且来自C#的背景，我对完全一致的“干净代码”产生了痴迷，因此远离了漂亮的系统。*名称空间回到了构成Win32 API头文件的#定义的混乱，这有点文化冲击

在阅读了MSDN按字母顺序排列的Win32核心函数列表后，我意识到Win32的API设计实际上是多么简单，不幸的是，它被过去25年来的所有污点所掩盖，包括许多对16位编程的引用，这些在今天的64位世界中是完全不相关的

我将很快开始一个新的C/C++项目，我正在考虑如何根据需要重新创建Win32的头文件。我可以把它设计得很漂亮，但它可以与现有程序保持100%的二进制（和源代码）兼容性（因为#定义最终解决了同样的问题）

我想知道过去是否有人尝试过这样做（谷歌什么也没发现），或者是否有人想劝阻我

另外一个我想的是，如何使用更干净的C Win32 API，可以在上面设计一个更干净和更容易使用的C++ Win32 API包装器，因为不会有来自旧的C Win32项的任何命名空间污染。 编辑：

---

我只是想澄清一下，我这样做并不是为了提高编译性能，也不是为了任何形式的优化，我完全知道编译器会删除所有未使用的东西。我在这里的目标是拥有一个令人愉快的Win32 header库（因为我不需要每次使用函数时都按下Caps lock）。

这样做没有意义。仅仅因为有额外的cruft并不意味着它被编译成二进制文件（任何未使用的东西都会被优化掉）。此外，如果任何事情都发生了变化（我不知道，可能是WM_INPUT的数字发生了变化），那么使用系统标题就容易多了。此外，什么更直观？我认为

#include

比

#include“a-windows-of-my-own.h”

更容易理解

而且，老实说，你根本不需要查看windows.h的内容。是的，我读过，是的，它很丑陋，但它做了我需要的，我不需要维护它

---

使用real

windows.h

的唯一缺点可能是它可能会将编译速度降低几毫秒。

不。这有什么意义？只需包含

，并定义一些宏，如

WIN32\u LEAN\u and\u MEAN

，

VC\u EXTRALEAN

，

NOGDI

，

NOMINMAX

，等等，就可以删除不希望/不需要加快编译速度的内容。

不要这样做

这可能是可能的，但这将需要很长时间，并可能导致微妙的错误

---

然而，更重要的是，这将使除您之外的任何人都无法维护您的程序。

尽管Win32头可能被认为是“凌乱的”，但您几乎不必（或不想）查看它们内部。您需要知道的全部内容都记录在Win32 SDK中。头文件的确切内容是实现细节

其中有大量内容需要花费大量时间，而且复制起来也不必要挑剔，特别是与不同版本的Win32 SDK相关的内容

我建议：

#include <windows.h>

#包括

在我看来，这是一种不好的做法。通过尽可能遵守标准实践，并尽可能利用平台实现整洁和简洁。你需要假设微软在他们自己的平台上拥有最终的专业知识，有些方面超出了你现在所知道的。简单地说，这是他们的产品，他们最了解

通过滚动您自己的：

• 。。。您脱离了Microsoft的API，因此Microsoft无法再通过其标准渠道向您提供更新
• 。。。你可能会因为自己的自大而引入bug，感觉自己已经发现了一些东西，而自己还没有发现
• 。。。您将浪费大量的时间而得不到任何实际的好处（因为C头不会给编译的二进制文件带来任何开销）
• 。。。你最终会创建一个不那么优雅的项目

---

最优雅的代码是携带更多实际程序逻辑LOC和尽可能少的“内务管理”LOC的代码（即与手头任务没有直接关系的代码）。不要忘记利用平台SDK头使项目更加优雅。

这在过去已经尝试过

---

在其

include

目录中，包含其自己版本的

windows.h

。这可能是为了使头与gcc一起工作。我不知道它是否适用于Microsoft编译器。

也许您可以在这里给出一两个函数的示例。这听起来更像是为了方便起见，您计划编写一个精简包装器库——在某种程度上，这与ATL或MFC所做的（甚至是window自己的，它有SendMessage和其他的包装器）没有太大区别。优点：做得好，它可以提高生产力并帮助避免常见的Win32 API陷阱（例如，使用注册表API获得正确的类型）。主要的缺点是，其他人在看你的代码时可能不知道你在做什么-这在你的情况下可能不是问题。看起来你得到了一个非常响亮的否定！更像是几秒钟…每个源文件：：-）@R：如果您使用的是预编译的头文件，则不会。