C++：windows.h 通常是一个高效的代码库吗？
我听到一些人抱怨在 C++ 应用程序中包含 Windows 头文件并使用它。他们提到这是低效的。这只是一些都市传说还是背后确实有一些确凿的事实？换句话说，如果您认为它是有效或低效的，请用事实解释这是如何发生的。
我不是 C++ Windows 程序员大师。如果有详细的解释，我们将不胜感激。
*编辑：我想知道编译时和执行时的情况。抱歉没有提及。
I heard some people complaining about including the windows header file in a C++ application and using it. They mentioned that it is inefficient. Is this just some urban legend or are there really some real hard facts behind it? In other words, if you believe it is efficient or inefficient please explain how this can be with facts.
I am no C++ Windows programmer guru. It would really be appreciated to have detailed explanations.
*Edit: I want to know at compile time and execution. Sorry for not mentioning it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
windows.h不是“代码库”。它是一个头文件，不包含任何可执行代码（除了宏定义，但它们仍然没有编译 - 如果您使用它们，它们的扩展就会被编译）。因此，严格从性能角度来看，仅仅包含它只会对编译时间产生影响。不过，这一点相当重要 - 例如，如果使用 VS2010 附带的 Platform SDK 标头，
#include会扩展到约 2.4Mb 的代码 - 并且所有代码都必须由编译器解析和处理。话又说回来，如果您使用预编译头（在这种情况下您可能应该这样做），它不会影响您。
windows.his not a "code library". It's a header file, and doesn't contain any executable code as such (save for macro definitions, but those still aren't compiled - their expansions are, if and when you use them).As such, looking at it strictly from performance perspective, merely including it has any effect solely on compilation time. That one is rather significant, though - for example, if using Platform SDK headers that come with VS2010,
#include <windows.h>expands to ~2.4Mb of code - and all that code has to be parsed and processed by the compiler.Then again, if you use precompiled headers (and you probably should in this scenario), it wouldn't affect you.
如果你预编译它，那么编译速度的差异几乎察觉不到。预编译的缺点是每个项目只能有一个预编译头，因此人们倾向于制作一个“precompiled.h”（或“stdafx.h”）并包含 windows.h、boost、stl 和所有内容否则他们需要在那里。当然，这意味着您最终会在每个 .cpp 文件中包含 windows.h 内容，而不仅仅是需要它的文件。这在跨平台应用程序中可能是一个问题，但是您可以通过在静态库（预编译了 windows.h）中执行所有特定于 win32 的内容并链接到主可执行文件中的内容来解决这个问题。
在运行时，windows.h 中的内容与 Windows 中的裸机差不多。所以在这方面确实不存在“效率低下”的情况。
我想说，大多数从事 Windows GUI 工作的人都会使用第 3 方库（Qt、wxWidgets、MFC 等），这些库通常位于 windows.h 中定义的 Win32 内容之上。 （在大多数情况下），正如我所说，在 Windows 上，windows.h 中的内容基本上是裸机。
If you precompile it, then the compilation speed difference is barely noticeable. The downside to precompiling, is that you can only have one pre-compiled header per project, so people tend to make a single "precompiled.h" (or "stdafx.h") and include windows.h, boost, stl and everything else they need in there. Of course, that means you end up including windows.h stuff in every .cpp file, not just the ones that need it. That can be a problem in cross-platform applications, but you can get around that by doing all your win32-specific stuff in a static library (that has windows.h pre-compiled) and linking to that in your main executable.
At runtime, the stuff in windows.h is about as bare-metal as you can get in Windows. So there's really no "inefficiencies" in that respect.
I would say that most people doing serious Windows GUI stuff would be using a 3rd-party library (Qt, wxWidgets, MFC, etc) which is typically layered on top of the Win32 stuff defined in windows.h (for the most part), so as I said, on Windows, the stuff in windows.h is basically the bare metal.
有很多地方可以发挥效率的作用。
包含
通过使用预编译头可以在一定程度上减轻增加的编译时间，但是这也带来了更多的代码库复杂性（您至少需要 2 个 PCH 文件），以及 PCH 特有的一些令人头疼的问题。尽管如此，对于大型 Windows 项目，我通常使用 PCH。对于玩具或公用事业项目，我通常不会这样做，因为这比它的价值更麻烦。
运行时效率也会发挥作用。据我所知，如果您
#include但不使用任何这些设施，那么它至少不会对程序的运行时行为产生影响调用额外的代码之类的事情。然而，可能还有其他我不知道的运行时影响。至于“白象”这个大问题：“Windows 高效吗？”我不会在这里讨论这一点，只是说：使用 Windows 与其他任何东西都很相似，它的效率如何或低效主要取决于您以及您对如何使用它的了解程度。然而，您会得到与您询问的人一样多的不同意见，从“Winblowz 很糟糕”到“我喜欢 Windows，它太棒了”。忽略它们。如果您需要的话，请学习在 Windows 中编写代码想要然后自己拿主意。
There are multiple places where efficiency comes in to play.
Including
<windows.h>will substantially increase compile times and bring in many symbols and macros. Some of these symbols or macros may conflict with your code. So from this perspective, if you don't need<windows.h>it would be inefficient at compile time to bring it in.The increased compile time can be mitigated somewhat by using precompiled headers, but this also brings with it a little more codebase complexity (you need at least 2 more files for the PCH), and some headaches unique to PCHs. Nonetheless, for large Windows project, I usually use a PCH. For toy or utility projects, I typically don't because it's more trouble than it's worth.
Efficiency also comes in to play at runtime. As far as I know, if you
#include <windows.h>but don't use any of those facilities, it will have no effect on the runtime behavior of your program at least as far as calling extra code and that kind of thing. There may be other runtime effects however that I'm not aware of.As far as the big White Elephant question, "Is Windows Efficient?" I'll not go in to that here other than to say this: Using Windows is much like anything else in that how efficient or inefficient it is depends mostly on you and how well you know how to use it. You'll get as many different opinions on this as people you ask however, ranging from "Winblowz sucks" to "I love Windows, it's awesome." Ignore them all. Learn to code in Windows if you need & want to and then make up your own mind.
正如已经指出的，#include windows.h 会减慢编译时间。您可以使用预编译标头，或者很好地将 Windows 调用隔离到需要它们帮助的模块。
另外，您可以在 windows.h 包含之前添加这些预处理定义，如下所示：
它将减少 windows.h 和子包含头文件中的定义数量。稍后您可能会发现需要删除精简的内容，但首先尝试一下，直到编译器抱怨缺少 def。
命名空间冲突是一个合理的抱怨，但从技术上讲与效率无关，除非您计算个人使用时间的效率。考虑到将有成千上万的定义被放入您的名称空间中，在某些时候必然会发生冲突，这可能会非常令人恼火。只需采用将 Windows 调用隔离到模块中的做法，就可以了。为此，请将 #include windows.h 放入 .cpp 文件中，而不是 .h 文件中。
我认为没有理由认为包含 windows.h 会影响可执行文件的运行时性能。您只是将大量定义添加到编译器使用的上下文中。您甚至没有将所有定义放入已编译的代码中 - 只是根据源代码 (.cpp) 中使用的任何定义进行分配、函数调用和引用。
另一个论点是，Windows API 类型和函数本质上是浪费资源或执行效率低下。也就是说，如果您想创建一个文件，则需要将一些巨大的结构传递给 Windows API。尽管如此，我认为大部分都是小事明智/大事愚蠢的想法。逐案评估 Windows API 性能问题，并在可能且有价值的情况下替换低效代码。
As has been noted, #including windows.h slows down compile time. You can use precompiled headers or do a good job of isolating the windows calls only to modules that need them to help with that.
Also, you can add these preproc definitions before the windows.h include like so:
It will reduce the number of definitions from windows.h and sub-included header files. You may find later on that you need to remove the lean-and-mean, but try it first and wait until the compiler complains about a missing def.
The namespace conflicts are a legitimate gripe, but technically have nothing to do with efficiency, unless you count efficiency of your personal use of time. Considering how many thousands of definitions will be thrown into your namespace, conflicts are bound to occur at some point, and that can be severely irritating. Just use the practice of isolating your Windows calls into modules, and you will be fine. For this, put #include windows.h in the .cpp file, and not the .h file.
I see no basis for thinking that the runtime performance of the executable will be impacted by including windows.h. You are only adding a large number of definitions to the context used by the compiler. You aren't even putting all the definitions into your compiled code--just allocations, function calls, and referencing based on any definitions used in your source code (.cpp).
Another argument could be made that the Windows API types and functions are inherently wasteful of resources or perform inefficiently. I.e. if you want to create a file, there is some monstrous structure to pass to the Windows API. Still, I think most of this is penny-wise/pound-foolish thinking. Evaluate Windows API performance problems case-by-case and make replacements for inefficient code where possible and valuable.
一般来说，包含 windows.h 是必要的：如果您需要 Windows 函数，则必须包含它。我认为你指的是（除其他外）windows.h 的嵌套包含。也就是说，您包含一个 .h，该 .h 本身包含 windows.h，并且您还在 .cpp 文件中包含 windows.h。当然，这会导致效率低下，因此您必须在代码中很好地研究每个 .h 文件中包含哪些 .h 文件，并避免间接包含 windows.hn 次。
In general, including windows.h is a necessity: if you need windows functions, you have to include it. I think what you're refering to is (among other things) nested inclusion of windows.h. That is, you include a .h that includes itself windows.h, and you also include windows.h in your .cpp file. This leads to inefficiencies, of course, so you have to study very well in your code what .h files are included in each .h file, and avoid including, say, windows.h n times indirectly.