Question

我发现自己最近在Win32上做了更多的C / C ++代码，并且来自C＃背景我已经开始着迷于“干净的代码”，它完全一致，所以远离美丽的System。*名称空间回到构成Win32 API头文件的#defines的混搭是一种文化冲击。

在阅读了MSDN按字母顺序排列的Win32核心功能列表之后，我意识到Win32的API设计实际上是多么简单，不幸的是它被过去25年的所有瑕疵笼罩着，包括许多完全引用16位编程的内容与今天的64位世界无关。

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

我想知道过去有没有人尝过这个（谷歌什么都没有），或者是否有人想劝阻我。

我想到的另一件事是，如何使用更干净的C Win32 API，可以在顶部设计更干净，更易于使用的C ++ Win32 API包装器，因为旧的C Win32不会有任何命名空间污染项目

编辑：

只是为了澄清，我不是为了提高编译性能或进行任何类型的优化，我完全清楚编译器会废除所有未使用的内容。我的任务是拥有一个Win32标头库，很高兴能够使用（因为每次使用函数时我都不需要按下Caps-lock）。

Answer 1

不要这样做。

这可能是可能的，但这需要很长时间，可能会导致细微的错误。

然而，更重要的是，它将使您的程序完全不可能为您以外的任何人维护。

Answer 2

这样做没有意义。仅仅因为有额外的瑕疵并不意味着它被编译成二进制文件（任何未使用的都将被优化掉）。此外，在极端情况下，任何事情都会发生变化（我不知道，也许WM_INPUT的号码更改），使用系统标题会更容易。此外，什么更直观？我认为#include <windows.h>比#include "a-windows-of-my-own.h"更容易理解。

另外，老实说，你甚至不需要查看windows.h的内容。是的我已经读过它了，是的它像罪一样丑陋，但是我做了我需要它而且我不需要维护它。

使用真实windows.h的唯一缺点可能是它可能会使编译速度减慢几毫秒。

Answer 3

没有。重点是什么？只需添加<windows.h>，并定义一些宏，例如WIN32_LEAN_AND_MEAN，VC_EXTRALEAN，NOGDI，NOMINMAX等，以删除您不想要的内容/需要加快编译时间。

Answer 4

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

其中有大量内容耗费时间并且不必要地复制，特别是与不同版本的Win32 SDK有关。

我建议：

#include <windows.h>

Answer 5

在我看来，这是不好的做法。通过尽可能保持标准实践并尽可能地从平台上获得利用来实现整洁和简洁。您需要让Microsoft在自己的平台上拥有最终的专业知识，其中某些方面超出了您现在所知的范围。简单来说，这是他们的产品，他们最了解。

滚动自己：

...您从Microsoft的API分支出来，因此Microsoft无法再通过其标准渠道向您提供更新
...你可能会因为自己的傲慢而引入错误，感觉你已经想到了什么，而你没有
...你浪费了很多时间没有任何实际好处（因为C头不会对编译后的二进制文件产生任何开销）
...你最终会创建一个不太优雅的项目

最优雅的代码是携带更多LOC实际程序逻辑并且尽可能少地用于“内务处理”（即与手头任务不直接相关的代码）的代码。不要无法利用Platform SDK标头来使您的项目更加优雅。

Answer 6

过去曾尝试过这种做法。

在include目录中，MinGW包含自己的windows.h版本。据推测，这可以使标题与gcc一起使用。我不知道它是否适用于Microsoft编译器。

重新创建Win32的标题是一个好主意吗？

6 个答案: