显式实例化和extern template能显著减少C++模板编译时间。通过在单个.cpp文件中显式实例化模板并用extern template声明避免其他编译单元重复实例化，实现集中化代码生成，避免重复工作。同时，类型擦除、模板瘦身、PIMPL模式及C++20模块等设计和实践也能有效优化模板编译效率，降低整体编译负担。
C++模板的编译速度，特别是实例化时间，确实是很多大型项目面临的痛点。在我看来，核心问题在于编译器在每个用到模板的编译单元（
.cpp文件）中，都可能对相同的模板类型进行重复的实例化。要减少这种重复劳动，关键在于集中管理和控制模板的实例化过程，告诉编译器“这个模板类型我已经处理过了，别再费心了”。
解决方案
要显著减少C++模板的实例化时间，最直接且有效的方法是结合使用显式实例化（Explicit Instantiation）和extern template
声明。这两种机制协同工作，能将模板实例化的工作集中到少数几个编译单元中，从而避免在每个包含模板定义的头文件的编译单元中都重复生成代码。
具体来说，显式实例化允许你在一个
.cpp文件中强制编译器为特定的模板类型生成代码。一旦这些代码生成，其他编译单元就可以直接链接到它们，而无需再次实例化。
extern template则是一个声明，它告诉编译器：“别在这个编译单元里实例化这个模板了，它会在别处被显式实例化。”这就像是给编译器一个“通行证”，让它知道在哪里可以找到已实例化好的模板代码。
这种方法的核心思想是将模板的定义（通常在头文件中）与它的具体类型实例化（在
.cpp文件中）解耦。这样，当头文件被多个源文件包含时，只有定义被包含，而实际的代码生成只发生一次。
立即学习“C++免费学习笔记（深入）”；
为什么C++模板会导致编译时间过长？
说实话，C++模板在带来巨大灵活性和代码复用性的同时，也确实是编译时间的“大户”。究其原因，我觉得主要有这么几点：
首先，最核心的是实例化模型。C++标准规定，模板的定义（包括函数体、成员函数等）必须在编译时对编译器可见，以便它能为每个具体类型参数生成一份专门的代码。这意味着，你把模板写在头文件里，然后这个头文件被十个
.cpp文件包含，那么编译器就可能在这十个文件里都尝试生成一遍
MyTemplate<int>的代码。这种重复的劳动，就像是让十个工人各自在自己的车间里生产一模一样的零件，效率自然不高。
其次，是“一切都在头文件里”的哲学。为了让编译器能看到模板的完整定义，我们通常把模板的声明和实现都放在头文件中。这导致了头文件变得非常庞大，包含了大量的代码和依赖。当这些大头文件被广泛包含时，每个编译单元都需要解析和处理这些海量信息，即使其中大部分信息可能与当前编译单元无关。这种“广撒网”式的包含策略，无疑增加了编译器的负担。
再者，模板元编程（TMP）的滥用也会加剧问题。虽然TMP能实现一些非常高级的编译期计算和优化，但它的本质是在编译期执行复杂的递归和条件判断。这会消耗大量的编译器资源，使得编译过程变得异常漫长。有时候，为了那么一点点运行时性能的提升，我们付出了巨大的编译时间代价，这笔账，真的需要好好算算。
最后，错误信息的复杂性也是一个隐性因素。当模板代码出错时，编译器生成的错误信息往往冗长且难以理解，这会增加调试时间，间接拉长了开发周期，也算是“编译时间”的一部分吧，毕竟我们总是在编译-修改-再编译的循环里打转。
显式实例化和extern template
是如何加速编译的？
在我看来，显式实例化（Explicit Instantiation）和
extern template就像是给编译器下达了明确的指令，告诉它哪些模板实例在哪里生成，哪些地方又不需要重复生成，从而极大地减少了冗余工作。
显式实例化的核心思想是“集中生产”。我们知道，当一个模板被某个具体类型使用时（比如
std::vector<int>），编译器会为这个特定的类型生成一份代码。如果
std::vector<int>在你的十个
.cpp文件中都被用到，那么在没有特殊处理的情况下，编译器可能在每个
.cpp文件中都生成一份
std::vector<int>的代码（尽管链接器最终会合并它们，但编译阶段的重复工作是实实在在的）。
有了显式实例化，你可以在一个单独的
.cpp文件（比如
my_templates.cpp）中，明确告诉编译器：“请为
MyTemplate<int>生成一份完整的代码。”
// my_template.h
template <typename T>
class MyTemplate {
public:
void doSomething(T val);
};
template <typename T>
void MyTemplate<T>::doSomething(T val) {
// 具体的实现
// std::cout << "Doing something with: " << val << std::endl;
}
// my_templates.cpp
#include "my_template.h"
#include <iostream>
// 显式实例化MyTemplate<int>
template class MyTemplate<int>; // 实例化类模板
template void MyTemplate<int>::doSomething(int val); // 实例化成员函数
// 或者直接实例化整个类，通常会包含所有成员函数
// template class MyTemplate<int>;这样，
MyTemplate<int>的完整代码只会在
my_templates.cpp中生成一次。其他
.cpp文件只要包含了
my_template.h，并使用了
MyTemplate<int>，它们就只会看到模板的声明，而不会触发新的代码生成。链接器在最后阶段会把这些使用点和
my_templates.cpp中生成的代码连接起来。
而extern template
则是一个“请勿打扰”的声明。它通常用在头文件中，或者在那些会使用到特定模板实例但又不想触发实例化的
.cpp文件中。它的作用是告诉当前的编译单元：“嘿，这个
MyTemplate<double>的实例化代码会在别的地方提供，你不用操心了，也别在这里生成代码。”
// my_template.h
template <typename T>
class MyTemplate {
public:
void doSomething(T val);
};
template <typename T>
void MyTemplate<T>::doSomething(T val) {
// 具体的实现
// std::cout << "Doing something with: " << val << std::endl;
}
// 声明MyTemplate<double>会在别处实例化
extern template class MyTemplate<double>;
extern template void MyTemplate<double>::doSomething(double val); // 也可以单独声明成员函数然后在某个
.cpp文件中（比如
my_templates_extern.cpp），你再进行显式实例化：
// my_templates_extern.cpp #include "my_template.h" #include <iostream> // 显式实例化MyTemplate<double> template class MyTemplate<double>;
通过这种组合，
MyTemplate<double>的代码也只会在
my_templates_extern.cpp中生成一次。其他包含了
my_template.h的
.cpp文件，由于有了
extern template的声明，就不会再重复实例化
MyTemplate<double>了。这种机制避免了大量的重复编译工作，从而显著提升了整体的编译速度。这就像是把散落在各处的“零件生产”任务，统一规划到了几个中央工厂，效率自然就上来了。
除了显式控制实例化，还有哪些设计模式或实践能优化模板编译效率？
除了直接控制模板实例化，我们还有一些更宏观的设计模式和日常实践，也能在一定程度上缓解模板带来的编译压力。这不仅仅是技术细节，更关乎我们如何思考和组织代码。
一个非常重要的思路是类型擦除（Type Erasure）或基于多态的设计。当你的模板需要处理多种类型，但这些类型在某些操作上行为一致时，可以考虑引入一个非模板的基类和虚函数。这样，模板的复杂性就被“擦除”了，对外暴露的是一个统一的、非模板的接口。例如，
std::function就是一个典型的类型擦除例子，它能持有任何可调用对象，而自身却是一个非模板类。
// 假设你有一个模板类，需要处理不同类型的处理器
template<typename ProcessorType>
class TaskRunner {
ProcessorType processor;
public:
void runTask() { processor.process(); }
};
// 如果你有很多ProcessorType，每次实例化都会生成代码
// 使用类型擦除：
class IProcessor { // 非模板基类
public:
virtual ~IProcessor() = default;
virtual void process() = 0;
};
template<typename T>
class ConcreteProcessor : public IProcessor { // 模板实现类
T data;
public:
ConcreteProcessor(T d) : data(d) {}
void process() override { /* do something with data */ }
};
class GenericTaskRunner { // 非模板的运行器
std::unique_ptr<IProcessor> processor;
public:
template<typename T>
GenericTaskRunner(T data) : processor(std::make_unique<ConcreteProcessor<T>>(data)) {}
void runTask() { processor->process(); }
};
// 现在，GenericTaskRunner本身不再是模板，只有ConcreteProcessor是模板，
// 且通常只在GenericTaskRunner的构造函数中实例化一次。这种方式将模板实例化推迟到更具体的、更少重复的地方，或者干脆用运行时多态替换编译时多态，牺牲一点点运行时性能，换取编译时间的巨大收益。
其次，保持模板的“瘦身”。一个模板应该尽可能地小巧、专注，只做它最核心的事情。避免在模板类或模板函数中塞入大量的无关逻辑、复杂的依赖关系。模板内部如果需要一些辅助函数或工具类，尽量让它们是非模板的，或者将它们抽离成独立的、显式实例化的模板。这样，当模板被实例化时，编译器需要处理的代码量就减少了。
再者，PIMPL（Pointer to Implementation）模式虽然主要用于减少头文件依赖和加快非模板类的编译，但其思想也可以间接应用到模板场景。如果你的模板类内部有一些复杂的、不依赖于模板参数的具体实现细节，可以考虑将这些细节封装到一个非模板的
Impl类中，并通过指针在模板类中引用。这样，
Impl类的修改就不会导致模板类及其所有实例的重新编译。当然，这会增加代码的复杂性，需要权衡。
最后，一个长远的解决方案是关注C++20 Modules。模块是C++标准委员会为了解决头文件机制带来的编译慢、依赖复杂等问题而引入的。模块允许你将代码编译成一个独立的单元，其他代码可以直接导入这个单元，而无需重新解析和编译其内容。对于模板来说，模块可以更好地管理其定义和实例化，有望大幅度减少重复编译。虽然目前普及度还不高，但未来这无疑是解决C++编译速度问题的终极武器之一。当然，现在我们主要还是得依靠现有的工具和实践来优化。
