Visual Studio 2010、Intellisense 和 PCH：丑陋的 stdafx.h 的替代品是什么？
我最近切换到 Visual Studio 2010，并且在使用 boost 库时，Intellisense 不会花费半分钟时间显示，微软的建议似乎使用预编译头。
只是我以前从未使用过它们（除非被丑陋的 ATL Wizards (TM) 强迫使用），所以我四处寻找以弄清楚它们是如何工作的。
基本上，大集中式 stdafx.h 方法似乎是完全错误的。我从来不想在我的所有源代码中包含（即使是便宜的）一大堆头文件。由于我不使用 Windows 库（我制作 C++/CLI 更高级别的包装器，然后使用 .NET 与外界通信），所以我没有“一整车不变的巨大标头”。只是 boost 和标准库头分散在各处。
我希望找到一些“为每个源文件自动生成一个预编译头”的技巧，或者至少是一些“最佳实践”，但大多数人似乎很乐意将世界包含到 stdafx.h 中。
我可以使用哪些选项来在每个源文件的基础上使用预编译头？我并不真正关心构建时间（只要它们不飙升），我只是希望智能感知工作快。
I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.
Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.
Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.
There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.
I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.
What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，您读错了这篇文章。每个文件都不会被编译两次。文件 stdafx.cpp 在执行其他操作之前先使用 /Yc（c，用于创建）编译一次，然后项目中的每个其他文件都使用 /Yu（u，用于使用）编译一次，并导入先前创建的保存状态的结果来自 stdafx.cpp。
其次，这篇文章已经有 7 年历史了，并且谈论的是 VC++ 6，所以你应该开始不信任它。但即使假设其中的信息仍然适用于 VC++ 2008 或 2010，这似乎也是一个糟糕的建议。它推荐使用
/pragma hdrstop的方法是寻找问题的解决方案。如果您的标头包含您不希望在每个文件中出现的内容，那么它们就不应该出现在您的预编译标头中。For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.
Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using
/pragma hdrstopis solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.您的问题基本上似乎是 VS2010 中 Boost 的 Intellisense 速度很慢？我没有针对此问题的直接解决方案，但是 Visual Assist X 可以作为您的选择吗？我现在已经在各种版本的 Visual Studio 中使用它并且非常高兴。这不是直接的解决方案，但它可能对您有用。
Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.
如果您正确使用预编译头文件，它们并不会太糟糕。
不要将它们用作正确且精确的 #include 的替代品，而应将它们用作加快速度的方法。通过使预编译头在发布版本中不执行任何操作，仅在调试中加快速度来实现此目的。
Precompiled headers aren't too bad if you use them properly.
Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.
你错了，每个文件只编译一次。您有一个使用 /Yc 编译的 .cpp 文件，其余文件使用 /Yu 编译。 /Yc 的文件默认为 stdafx.cpp，包含一行 #include "myMainHeader.h"（更改了默认名称） 所有其他 .cpp 文件必须以 #include "myMainHeader.h" 开头/Yc 文件编译后，保存了编译器的整个内部状态。当编译每个其他文件时，会加载该文件。这就是为什么您必须从包含 PCH 开始，以便 /Yu 选项不会更改编译结果，只会更改时间。 Xcode 没有提出此要求，并且无论您的 .cpp 文件是否以正确的 include 指令开头，都会使用 PCH。我使用过依赖于此的库，如果没有 PCH 就无法构建。
You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.