在大型面向对象项目中，重要的原因是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中被模仿，而且通常也被模仿，这不会重现这个问题。

一些原因是:

1) c++语法比c#或Java更复杂，需要更多的时间来解析。

2)(更重要的是)c++编译器生成机器代码，并在编译期间进行所有优化。c#和Java只走了一半，将这些步骤留给JIT。

编译语言总是比解释语言需要更大的初始开销。此外，也许您没有很好地组织您的c++代码。例如:

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

编译速度比:

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

Most answers are being a bit unclear in mentioning that C# will always run slower due to the cost of performing actions that in C++ are performed only once at compile time, this performance cost is also impacted due runtime dependencies (more things to load to be able to run), not to mention that C# programs will always have higher memory footprint, all resulting in performance being more closely related to the capability of hardware available. The same is true to other languages that are interpreted or depend on a VM.

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

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

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

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

简单地回答这个问题，c++是一种比市场上其他可用语言复杂得多的语言。它有一个遗留的包含模型，可以多次解析代码，并且它的模板库没有针对编译速度进行优化。

语法和ADL

让我们通过一个非常简单的例子来看看c++的语法复杂性:

x*y;

虽然你可能会说上面是一个带有乘法的表达式，但在c++中不一定是这样。如果x是一个类型，那么该语句实际上是一个指针声明。这意味着c++语法是上下文敏感的。

下面是另一个例子:

foo<x> a;

同样，你可能认为这是foo类型变量“a”的声明，但它也可以被解释为:

(foo < x) > a;

这将使它成为比较表达式。

c++有一个叫做参数依赖查找(ADL)的特性。ADL建立规则来控制编译器如何查找名称。考虑下面的例子:

namespace A{
  struct Aa{}; 
  void foo(Aa arg);
}
namespace B{
  struct Bb{};
  void foo(A::Aa arg, Bb arg2);
}
namespace C{ 
  struct Cc{}; 
  void foo(A::Aa arg, B::Bb arg2, C::Cc arg3);
}

foo(A::Aa{}, B::Bb{}, C::Cc{});

ADL规则规定，考虑函数调用的所有参数，我们将寻找名称“foo”。在这种情况下，将考虑所有名为“foo”的函数进行重载解析。这个过程可能需要时间，特别是如果有很多函数重载。在模板化上下文中，ADL规则变得更加复杂。

# include

这个命令可能会极大地影响编译时间。根据所包含文件的类型，预处理器可能只复制几行代码，也可能复制数千行。

此外，编译器不能优化此命令。如果头文件依赖于宏，则可以复制可以在包含前修改的不同代码段。

对于这些问题，有一些解决方案。您可以使用预编译头文件，这是编译器在头文件中解析内容的内部表示。然而，这离不开用户的努力，因为预编译的头文件假定头文件不依赖于宏。

模块特性为这个问题提供了语言级的解决方案。它可以从c++ 20版本开始使用。

模板

The compilation speed for templates is challenging. Each translation unit that uses templates needs to have them included, and the definitions of these templates need to be available. Some instantiations of templates end up in instantiations of other templates. In some extreme cases, template instantiation can consume lots of resources. A library that uses templates and that was not designed for compilation speed can become troublesome, as you can see in a comparison of metaprogramming libraries provided at this link: http://metaben.ch/. Their differences in compilation speed are significant.

如果你想了解为什么一些元编程库在编译时间上比其他的更好，看看这个关于Chiel规则的视频。

结论

c++是一种编译缓慢的语言，因为编译性能在该语言最初开发时并不是最高优先级。结果，c++的特性在运行时可能有效，但在编译时不一定有效。

附注:我在Incredibuild工作，这是一家软件开发加速公司，专门加速c++编译，欢迎您免费试用。