Boost 非常棒，它很棒而且非常强大，但我每次在 Visual Studio 7.1 中构建解决方案时都讨厌它。
似乎 Boost 对构建时间有影响（不是正面的）。我无法从我的项目中删除所有 Boost 使用来比较构建时间，但我在小型项目上进行了尝试，并且差异很有意义。
我想问题在于 Boost 由数千个头文件组成，其中包含非常广泛的自身。因此，当我在头文件中包含 boost/function.hpp 时，可能会导致包含数百个 Boost 头。
有没有人有同样的经历？任何想法如何解决它？
粗略的想法：
PS。是的，Boost 还使用硬核模板，我猜这很难编译，所以成千上万的头文件不是唯一的问题。
【问题讨论】：
标签： c++ visual-studio visual-c++ boost build-process
我也喜欢提升很多
另一个可能很愚蠢的提示，但它是我计算机性能损失的主要来源：
【讨论】：
当然，包含 boost 会导致更长的编译时间 - 就像包含任何库一样。由于所有逻辑都在标头中实现，因此（主要）是模板库会导致相当大的性能损失。
我已经取得了很好的结果，包括预编译头文件中的（一个子集）提升。但是，我相信 MSVC 9 的收益最大。在 MSVC 7 上，我看到一些报告说模板的预编译标头经常会导致性能下降。确定您是否会看到性能提升的另一个关键方面是在预编译的标头中包含适当的标头。只包含您经常使用的标头，并确保它们永远不会更改（也就是说，在此处包含您自己的标头之前要三思而后行）
我不知道显式实例化是否有任何效果，尽管我对此表示怀疑。如果有人对此（无论编译器）有任何结果，那将非常有趣。
“准备”提升标头听起来像是在更改它们，这对我来说是个非常糟糕的主意。您不想最终维护自定义标题...
可能并不像您想象的那么不真实。始终尽可能多地使用forward declarations，以减少每个头文件的“足迹”。考虑使用Pimpl 模式来避免包含未反映在类的公共接口中的 boost 标头（题外话：我认为 Pimpl 通常是不必要的。相反，我尝试将类切成更小的部分，从而在“更清洁”的时尚）。只要您在使用这些类时保持一致，就不要害怕包含通用的通用类（例如 shared_ptr）（如果您在所有类中都使用它们，那么将它们从一个标题中隐藏起来不会有太大的好处） .
升级 MSVC（以支持并行构建）会有所帮助。但是，这在 C++ 中始终是一个问题。为了最大限度地减少问题，您需要非常严格并遵循指南以减少标头的占用空间。有时您应该查看包含子句并确保没有包含任何不必要的内容。如果您在标题中完成的包含列表越来越长，您可能做错了什么 - 大多数包含应该仅在 cpp 中。
【讨论】：
仅在真正需要时才包含 Boost 头文件是有意义的。包含其他头的头对IO造成压力，对编译时间有很大影响。前向声明在某种程度上有所帮助，但使用 Boost 可能会很痛苦。
在头文件中使用外部保护可以避免不必要的加载。像这样：
#ifndef BOOST_SHARED_PTR_HPP_INCLUDED
# include <boost/shared_ptr.hpp>
#endif
另一种避免标题级联的方法是使用"pimpl"-idiom，尤其是在处理复杂类时。然后可以包含复杂的 Boost 内容，并且只能由该编译单元使用。缺点是接口应该被设计成不需要 Boost 特定的东西。但是，打破依赖关系也可能是一件好事。
【讨论】：
正如您在帖子中提到的，boost 代码包含大量模板代码，需要大量 CPU 周期进行编译。与此相比，多个头文件的开销非常小。
您需要做的第一件事是找出导致编译延迟的头文件或代码行。通常不是包含头文件，而是在您自己的代码中使用其类/函数之一导致延迟。您可以通过注释掉代码片段直到编译再次快速，然后取消注释您的代码片段直到编译再次变慢来隔离负责的代码。然后你可以决定是否要用其他东西替换慢代码。您可以在这里权衡利弊或编译速度与漂亮的 boost 代码。
您还可以做一些其他事情：
【讨论】：