#include <Windows.h> 是不好的做法吗?

新手上路,请多包涵

我认为 #include <bits/stdc++.h> 是一种不好的做法已被 普遍接受,部分原因是它解析并包含每个标准标头,这几乎总是不必要的(它也是不可移植的,但这超出了我的观点)。与 using namespace std; 结合使用时更糟,因为现在您的命名空间中有大量常用名称,例如 next

然而,似乎 #include <Windows.h> 大多被认为是好的(我见过的大多数 Win32 程序都使用它),即使它在概念上与 #include <bits/stdc++.h> 的组合做同样的事情+ using namespace std;

根据 维基百科

windows.h 是 C 和 C++ 编程语言的特定于 Windows 的头文件,其中包含 Windows API 中所有函数的声明、Windows 程序员使用的所有常用宏以及各种函数使用的所有数据类型和子系统。它定义了大量可在 C 中使用的 Windows 特定函数。

为什么会这样?是否不可能包含我们使用的特定标头而不包含 <Windows.h>

原文由 Ayxan Haqverdili 发布,翻译遵循 CC BY-SA 4.0 许可协议

阅读 987
1 个回答

Msdn 文档明确告诉您 (a) 在哪个头文件中声明了一个函数,以及 (b) 您应该包含哪个头文件。

大多数函数会告诉您包含 windows.h ,例如 SendMessage

稍后添加或具有非常特定用例的某些功能只能通过其他头文件使用,例如 SetupDiEnumDeviceInfo

所以不,听从他们的建议并不是坏事。但是,我强烈建议在通过宏包含之前禁用它的某些部分,例如

#define NOMINMAX
#include <Windows.h>

因为否则你会得到一个 min 和一个 max 宏,它们会干扰 std::minstd::max

原文由 Timbo 发布,翻译遵循 CC BY-SA 4.0 许可协议

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题