从 boost 头文件中删除特定于编译器的代码答案

【问题标题】：Remove compiler-specific code from boost headers从 boost 头文件中删除特定于编译器的代码
【发布时间】：2011-02-23 12:59:23
【问题描述】：

boost 中的许多代码似乎是特定于编译器的解决方法或不同编译器的不同路径（尤其是在 mpl 等组件中）。当我使用 boost 时，我的构建时间会增加很多，即使我尝试将大部分内容隐藏在编译器防火墙 (PIMPL) 后面或使用预编译头文件时也是如此。

有没有办法为我实际使用的一个编译器预处理 boost 标头？我怀疑任何使标题（显着？）变小的东西都会产生一些影响。有没有人测试过这是否真的会提高速度？

不知道这对实际答案是否重要，但我主要使用 Visual Studio 2010。

【问题讨论】：

【解决方案1】：

如果您使用预编译的头文件，那就是对头文件进行预处理。如果 PCH 不会有所作为，那么您将无能为力。

编译时间可能来自过多的包含或复杂的模板实例化，而不是来自预处理器的大小或复杂性。

【讨论】：

【解决方案2】：

我怀疑任何使标题（显着？）变小的东西都会产生一些影响。

我猜你这样做之后，你会失望的。在像 boost 这样的复杂模板库中，花费最多时间的不是预处理，而是模板解析、实例化和优化。

你可以做一个实验，告诉你通过这种方式可以获得的上限：

我希望您所看到的只是项目构建时间的一小部分，即使这将比仅提升标头进行更多的预处理，因此预处理提升的收益会更小。

此外，如果您已经在预编译的头文件中包含了 boost，则预处理已经作为其中的一部分完成了，您很可能一无所获。

【讨论】：

我同意他们可能会花费大部分时间。但是仅仅优化标题可能仍然有一些好处。 I/O 复杂性不容忽视。
好的，很抱歉这么晚才回来 - 我刚刚尝试使用 /P /EP 进行编译，构建时间几乎与实际构建相同：-/
这真是出乎意料。数据总是正确的，但您是否 100% 确定您的设置正确？（当您执行 /P /EP 时，根本不进行编译 - 仅进行预处理。我发现很难相信您的所有构建时间都将完全是 I/O 和预处理）在我的情况下，从项目中随机选择一个文件编译需要 8-10 秒，预处理需要 4-5 秒（我没有测量整个项目，那会花费太长时间）。
相当肯定（但从来没有 100%，PEBKAC 太频繁了）——它也为每个编译单元生成“.i”文件，看起来像预处理文件（有很多额外的空白空间），所以我认为它正在工作。我刚刚使用这些设置从我的解决方案中重建了一个项目。也许值得注意的是，我的文件往往相对较小，因此相对开销可能很大。毕竟unity-builds似乎加快了速度一定是有原因的。
统一构建的好处不仅在于 I/O/预处理，而且（或者我会说大部分）类只解析一次，模板只实例化一次。