几个原因

头文件

每个编译单元都需要(1)加载和(2)编译数百甚至数千个头文件。 每个编译单元通常都需要重新编译它们， 因为预处理器确保编译头文件的结果可能在每个编译单元之间有所不同。 (宏可以在一个编译单元中定义，它会改变头文件的内容)。

这可能是主要原因，因为它需要为每个编译单元编译大量的代码， 此外，每个头文件都必须编译多次 (对于包含它的每个编译单元一次)。

链接

一旦编译完成，所有的目标文件都必须链接在一起。 这基本上是一个整体过程，不能很好地并行化，并且必须处理您的整个项目。

解析

语法非常复杂，难以解析，严重依赖上下文，并且很难消除歧义。 这要花很多时间。

模板

在c#中，List<T>是唯一被编译的类型，无论程序中有多少个List实例化。 在c++中，vector<int>和vector<float>是一个完全独立的类型，它们必须分别编译。

Add to this that templates make up a full Turing-complete "sub-language" that the compiler has to interpret, and this can become ridiculously complicated. Even relatively simple template metaprogramming code can define recursive templates that create dozens and dozens of template instantiations. Templates may also result in extremely complex types, with ridiculously long names, adding a lot of extra work to the linker. (It has to compare a lot of symbol names, and if these names can grow into many thousand characters, that can become fairly expensive).

当然，它们加剧了头文件的问题，因为模板通常必须在头文件中定义， 这意味着必须为每个编译单元解析和编译更多的代码。 在纯C代码中，标头通常只包含前向声明，但实际代码很少。 在c++中，几乎所有的代码都驻留在头文件中是很常见的。

优化

c++允许进行一些非常戏剧化的优化。 c#或Java不允许完全消除类(为了反射的目的，它们必须存在)， 但即使是一个简单的c++模板元程序也可以很容易地生成几十个或数百个类， 所有这些都在优化阶段被内联并再次消除。

此外，c++程序必须由编译器完全优化。 c#程序可以依赖JIT编译器在加载时执行额外的优化， c++没有任何这样的“第二次机会”。编译器生成的是它将要得到的优化。

机

c++被编译成机器代码，这可能比Java或. net使用的字节码更复杂(特别是在x86的情况下)。 (这只是出于完整性而提到的，因为它是在评论中提到的。 在实践中，这一步所花费的时间不太可能超过编译时间的一小部分)。

结论

这些因素中的大多数是由C代码共享的，这实际上是相当有效的编译。 在c++中，解析步骤要复杂得多，可能会占用更多的时间，但主要的问题可能是模板。 它们很有用，并使c++成为一种更强大的语言，但它们也在编译速度方面付出了代价。

构建C/ c++:到底发生了什么，为什么要花这么长时间

相当大一部分软件开发时间不是花在编写、运行、调试甚至设计代码上，而是花在等待代码完成编译上。 为了让事情变得更快，我们首先必须理解编译C/ c++软件时发生了什么。步骤大致如下:

配置 构建工具启动 依赖项检查 编译 链接

现在，我们将更详细地查看每个步骤，重点关注如何使它们更快。

配置

这是开始构建的第一步。通常意味着运行配置脚本或CMake、Gyp、SCons或其他工具。对于非常大的基于autotools的配置脚本，这可能需要一秒钟到几分钟的时间。

这一步很少发生。它只需要在更改配置或更改构建配置时运行。如果不改变构建系统，就没有多少事情可以加快这一步。

构建工具启动

这是在IDE上运行make或单击构建图标(通常是make的别名)时发生的情况。构建工具二进制文件启动并读取其配置文件以及构建配置，这通常是同一件事。

根据构建的复杂性和大小，这可能需要几秒到几秒的时间。这本身并没有那么糟糕。不幸的是，大多数基于make的构建系统在每次构建时都会调用几十到几百次make。这通常是由递归使用make(这是不好的)引起的。

应该注意的是，Make如此缓慢的原因并不是实现错误。Makefiles的语法有一些怪癖，使得真正快速的实现几乎不可能。当与下一步结合使用时，这个问题会更加明显。

依赖项检查

Once the build tool has read its configuration, it has to determine what files have changed and which ones need to be recompiled. The configuration files contain a directed acyclic graph describing the build dependencies. This graph is usually built during the configure step. Build tool startup time and the dependency scanner are run on every single build. Their combined runtime determines the lower bound on the edit-compile-debug cycle. For small projects this time is usually a few seconds or so. This is tolerable. There are alternatives to Make. The fastest of them is Ninja, which was built by Google engineers for Chromium. If you are using CMake or Gyp to build, just switch to their Ninja backends. You don’t have to change anything in the build files themselves, just enjoy the speed boost. Ninja is not packaged on most distributions, though, so you might have to install it yourself.

编译

此时，我们最终调用编译器。省事起见，以下是大致采取的步骤。

合并包括 解析代码 代码生成和优化

与流行的观点相反，编译c++实际上并没有那么慢。STL很慢，大多数用于编译c++的构建工具都很慢。然而，有更快的工具和方法来减轻语言中缓慢的部分。

使用它们需要一些体力，但好处是不可否认的。更快的构建时间会让开发人员更快乐，更敏捷，并最终产生更好的代码。

我能想到有两个问题可能会影响c++程序的编译速度。

POSSIBLE ISSUE #1 - COMPILING THE HEADER: (This may or may not have already been addressed by another answer or comment.) Microsoft Visual C++ (A.K.A. VC++) supports precompiled headers, which I highly recommend. When you create a new project and select the type of program you are making, a setup wizard window should appear on your screen. If you hit the “Next >” button at the bottom of it, the window will take you to a page that has several lists of features; make sure that the box next to the “Precompiled header” option is checked. (NOTE: This has been my experience with Win32 console applications in C++, but this may not be the case with all kinds of programs in C++.)

POSSIBLE ISSUE #2 - THE LOCATION BEING COMPILED TO: This summer, I took a programming course, and we had to store all of our projects on 8GB flash drives, as the computers in the lab we were using got wiped every night at midnight, which would have erased all of our work. If you are compiling to an external storage device for the sake of portability/security/etc., it can take a very long time (even with the precompiled headers that I mentioned above) for your program to compile, especially if it’s a fairly large program. My advice for you in this case would be to create and compile programs on the hard drive of the computer you’re using, and whenever you want/need to stop working on your project(s) for whatever reason, transfer them to your external storage device, and then click the “Safely Remove Hardware and Eject Media” icon, which should appear as a small flash drive behind a little green circle with a white check mark on it, to disconnect it.

我希望这对你有帮助;如果有，请告诉我!：）

在大型面向对象项目中，重要的原因是c++很难限制依赖关系。

私有函数需要在它们各自的类的public头文件中列出，这使得依赖关系比它们需要的更具传递性(传染性):

// Ugly private dependencies
#include <map>
#include <list>
#include <chrono>
#include <stdio.h>
#include <Internal/SecretArea.h>
#include <ThirdParty/GodObjectFactory.h>

class ICantHelpButShowMyPrivatePartsSorry
{
public:
    int facade(int);

private:
    std::map<int, int> implementation_detail_1(std::list<int>);
    std::chrono::years implementation_detail_2(FILE*);
    Intern::SecretArea implementation_detail_3(const GodObjectFactory&);
};

如果在头文件的依赖树中重复使用这种模式，就会产生一些间接包含项目中大部分头文件的“神头文件”。它们就像上帝对象一样无所不知，只是在绘制它们的包含树之前，这一点并不明显。

这会以两种方式增加编译时间:

它们添加到包含它们的每个编译单元(.cpp文件)的代码量很容易比cpp文件本身多很多倍。从这个角度来看，catch2.hpp是18000行，而大多数人(甚至是ide)开始难以编辑超过1000-10000行的文件。 编辑头文件时必须重新编译的文件数量不包含在依赖它的真实文件集中。

是的，有一些缓解措施，比如前向声明，它有缺点，或者pimpl习惯用法，它是非零成本抽象。尽管c++在你能做的事情上是无限的，但如果你偏离了它的本意，你的同事会想知道你到底在吸什么。

最糟糕的是:如果你仔细想想，在它们的公共头中声明私有函数的需求甚至是不必要的:成员函数的道德等效可以在C中被模仿，而且通常也被模仿，这不会重现这个问题。

在大型c++项目中减少编译时间的一个简单方法是创建一个包含项目中所有cpp文件的*.cpp包含文件并编译该文件。这将头爆炸问题减少到一次。这样做的好处是，编译错误仍然会引用正确的文件。

例如，假设你有a.cpp, b.cpp和c.cpp。创建一个文件:everything.cpp:

#include "a.cpp"
#include "b.cpp"
#include "c.cpp"

然后通过将everything.cpp编译项目

你得到的代价是程序运行得稍微快一点。在开发期间，这对您来说可能是一种冷漠的安慰，但一旦开发完成，并且程序只是由用户运行时，它就会变得非常重要。