模板的进阶（包括模板的分离编译问题、前置声明问题）

work_hard423

已于 2023-08-21 16:05:36 修改

阅读量500

点赞数 2

CC 4.0 BY-SA版权

分类专栏： C++ 文章标签： c++

于 2023-06-21 10:12:23 首次发布

本文链接：https://blog.youkuaiyun.com/work_hard423/article/details/131322276

C++ 专栏收录该内容

2 篇文章

订阅专栏

本文详细介绍了C++模板中的非类型参数、模板特化（全特化和偏特化）、模板的分离编译以及typename的关键字用法。通过实例展示了如何处理模板在编译过程中的各种情况，强调了模板使用中的优点和缺点，如代码复用和编译期膨胀问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

非类型模板参数

模板的特化（注意模板特化后，仍然是一个模板）

非类型模板参数

模板参数分为类型模板参数和非类型模板参数。

类型模板参数：出现在模板参数列表中，会被class或者typename修饰。如template<class A>，A被class修饰，因此为类型模板参数。

非类型模板参数：就是用一个常量作为类(函数)模板的一个参数，在类(函数)模板中可将该参数当成常量来使用，非类型模板参数就是一个常量。如template<size_t N>，N不被class或者typename修饰，所以是非类型模板参数，表示一个常量。注意浮点数、自定义类的对象是不允许作为非类型模板参数的，一般只有整形可以，比如size_t、int、longlong、char等等，注意char也算整形家族。

用途：用一种场景举例，如下图代码，如果我们想让类模板array中的_a数组是一个静态数组，想手动控制它的大小，则一般会像下图这样做。

这样做的确能够完成当前需求，但假如我现在增加一个需求，就是通过int类型实例化出的array类中的静态数组_a中的元素个数是100，通过double类型实例化出的array类中的静态数组_a中的元素个数为1000，此时光靠#define就无法完成要求了，因为要么只能为1000，要么只能为100。

那该怎么办呢？增加非类型模板参数，如下图代码就能解决问题，左右两种版本都可以，只不过右边给了非类型模板参数N缺省值。

模板的特化（注意模板特化后，仍然是一个模板）

模板的特化分为类模板的特化和函数模板的特化。函数模板特化后，仍然是一个函数模板；类模板特化后，仍然是一个类模板。不要误认为比如函数模板特化后就变成了一个具体的函数了。

函数模板的特化（特化版本的函数模板）

举个例子说明函数模板的特化。

如上图的Greater是个函数模板，用于比较left和right的大小，如果left大则返回true，反之返回false。可以看到当T是int，比较整形1和2时没有问题；当T是Date，比较日期类对象时也没有问题；但T是Date*时，通过日期类的指针对象比较日期类对象时会出问题，我们的期望是：对于日期类的指针对象Date*p1和Date*p2，能按照【解引用指针对象后获得的日期类对象的值】比较大小。但实际却不会按照我们的心愿来，只是按照指针的大小比较。

那该如何完成我们的期望呢？

有同学可能会想到通过比较类型去做特殊化处理，如下图，当T为Date*时我就做特殊处理。这是一种可行的思路，但如下图这样写不行，因为C++不支持==比较类型，只支持==比较对象，要通过typeid函数比较类型是否相同，比如通过typeid(T).name()==typeid(Date*).name()即可判断T是否为Date*。这里补充一个知识点，typeid(T).name()本质是返回一个C语言字符串，所以比较类型是否相同时是按照C语言字符串比较的，并且不同平台下typeid(T).name()的返回值是不同的，为T类型时，返回的不一定就是T本身，比如在Linux下，T为int类型时可能会返回一个int，也可能返回一个i，T为int*的类型时可能会返回一个int*，也可能返回一个pi。

除了上面的方法，我们还可以通过函数模板的特化，即针对某些类型进行特殊化处理完成我们的期望。别忘了我们的期望是：对于日期类的指针对象Date*p1和Date*p2，能按照【解引用指针对象后获得的日期类对象的值】比较大小。

先说说函数模板的特化的步骤。1. 必须要先有一个基础的函数模板，2. 关键字template后面接一对空的尖括号 <>，3. 函数名后跟一对尖括号，尖括号中指定需要特化的类型，【类型的数量】要和【基础的函数模板中的模板参数的数量】一致，4. 函数形参的类型必须要和函数名后的尖括号里的类型完全相同，如果不同编译器可能会报一些奇怪的错误。

如下图代码即可完成我们的期望。当存在通过Date*特化的版本后，如果实例化Greater函数模板时，T的类型为Date*，则不会走泛化的版本，而是直接走特化的版本。

类模板的特化（特化版本的类模板）

使用场景

依然拿上文的场景举例，在上面的例子中，我们通过函数模板greater的实例化出的函数比较大小，但除了通过函数比较大小外，还可以通过其他可调用对象，比如仿函数来比较大小，所以可以写一个类模板less出来。我们上面的期望是：对于日期类的指针对象Date*p1和Date*p2，能按照【解引用指针对象后获得的日期类对象的值】比较大小。之前我们是特化函数模板来完成这个期望，现在我们还可以特化类模板来完成这个期望，如下图代码所示。

这里解释一下，我们给了优先级队列的第三个模板参数Compare传了less<Date*>类，那么在调整堆时，就会通过less<Date*>类的对象（假如对象名为_com）比较两个Date*对象（假如名为x和y）的大小，注意特化后是按照指针解引用后的值比较大小的，比如_com(x，y)比较x和y这两个指针解引用后拿到的值的大小。注意给优先级队列的模板参数Compare传less类模板实例化出的类时，优先级队列是一个大堆。

全特化

类模板的特化分为全特化和偏特化。

全特化即是将模板参数列表中所有的参数都确定化。比如对于上图类模板，全特化的表现方式如下图所示。

步骤：将template的尖括号中的模板参数全部省略，然后在类模板名称的后面加上尖括号，然后写上特化版本的模板参数即可。特化版本的模板参数个数必须基础类模板的模板参数个数相等，因为特化版本的类模板不是独立的类模板，特化版本的类模板是依赖于基础版本的类模板的。注意下图中虽然没有可以发生变化的模板参数了，但我们依然认为全特化版本的类模板Data是一个类模板，而不是一个具体的类。

此时如果有Data<int，char>d，则会通过特化版本的类模板Date<int，char>实例化出具体的类Date<int，char>，而不是通过下图的基础版本的类模板实例化出Date<int，char>类。

偏特化

类模板的特化分为全特化和偏特化。

偏特化是指：针对模版参数进一步进行条件限制设计的特化版本。比如对于上图类模板，偏特化有两种表现方式。

第一种：部分特化

表示将模板参数列表中的一部分参数特化。

此时如果有Data<double，int>d或者Data<int，int>d，则会根据上图的特化版本的类模板去实例化Data<double，int>类或者Data<int，int>类，而不是通过下图的普通版本的类模板实例化。

第二种：将模板参数进行更进一步的限制

偏特化并不仅仅是指特化部分参数，还可以是指：将模板参数进行更进一步的条件限制。

此时如果有Data<double*，int*>d1，则会根据特化版本的类模板Data<T1*，T2*>实例化出Data<double*，int*>类，而不是根据下图的基础版本的类模板实例化。

此时如果有Data<int&，double&>d2，则会根据特化版本的类模板Data<T1&，T2&>实例化出Data<int&，double&>类，而不是根据下图的基础版本的类模板实例化。

分割线------------------------------------------------

如果将上文中的第一种情况（部分参数特化）和第二种情况（对模板参数作进一步的限制）混合，也是遵循上文所说的理论的，测试如下。

代码如下。

template<class T1,class T2>//基础版本的类模板
struct A
{
	A() { cout << "基础"; }
};


template<class T1>//通过【基础版本的类模板】特化出的特化版本的类模板1
struct A<T1, int>
{
	A() { cout << "特化"; }
};

template<class T1>//通过【基础版本的类模板】特化出的特化版本的类模板2
struct A<T1&,int>
{
	A() { cout << "特化&"; }
};

void main()
{
	A<int, int>a1;
    cout<<endl;
	A<int&, int>a2;
}

模板的分离编译

先来看看非模板的分离编译是如何实现的，这里拿普通函数的分离编译举例。

首先要知道以下几点。

一个编译单元（translation unit）是指一个.cpp文件以及它所#include的所有.h文件，.h文件里的代码将会被扩展到包含它的.cpp文件里，然后编译器将该.cpp文件编译成一个.obj文件，此时.obj文件里已经是全是二进制码了，但是不一定能够执行，因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由连接器（linker）进行连接成为一个.exe文件。

编译器将.c文件编译成.obj文件时，编译器只能单独编译某.c文件，它不知道也不必知道有没有其他的.c文件，所以各个.c文件被编译成.obj文件时，它们之间是完全相互独立的，完全互不干扰的。

在这个例子中，test. cpp和main.cpp各自被编译成不同的.obj文件（姑且命名为test.obj和main.obj），在main.cpp中，调用了f函数，然而当编译器编译main.cpp时，因为找不到f函数的定义，只能找到【main.cpp中所包含的test.h文件中的】一个关于void f();的声明，所以编译器将这里的f看作外部连接类型，即认为它的函数实现代码在另一个.obj文件中，本例也就是test.obj，也就是说，main.obj中实际没有关于f函数的哪怕一行二进制代码，而这些代码实际存在于test.cpp所编译成的test.obj中。在main.obj中对f的调用只会生成一行call指令，像这样：call f，注意call后面接的是经过编译器处理后的函数名称，所以实际上这里不是f，只是拿f举例。

call f这行指令实际上是一个jmp 0xABCDEF。这个地址可能是任意的，关键是这个地址上有一行指令来进行真正的call f动作。也就是说，这个.obj文件里面所有对f的调用都jmp向同一个地址，在后者那儿才真正”call”f。这样做的好处就是连接器修改地址时只要对后者的call XXX地址作改动就行了。但在编译时，这个jump后call XXX地址的指令显然是错误的，因为main.obj中并无一行f函数的实现代码，也就没有f函数的入口地址，也就是说根本没有XXX这个地址。那怎么办呢？这就是连接器的任务，连接器负责在其它的.obj中（本例为test.obj）寻找f的实现代码，找到以后将call f这个指令的调用地址换成实际的f的函数入口地址。需要注意的是：连接器实际上将工程里的.obj“连接”成了一个.exe文件，而它最关键的任务就是寻找一个外部连接符号在另一个.obj中的地址，然后将call 后的XXX替换成它。

但是，连接器是如何找到f的实际地址的呢（在本例中这处于test.obj中），.obj文件中有一个符号导入表和符号导出表（import table和export table）其中将所有符号和它们的地址关联起来。这样连接器只要在test.obj的符号导出表中寻找符号f（当然C++对f作了处理，名字不一定叫f，这里只是以f举例）的地址就行了，然后作一些偏移量处理后（因为是将两个.obj文件合并，当然地址会有一定的偏移，这个连接器清楚）写入main.obj中的符号导入表中f所占有的那一项即可。

这就是大概的过程。其中关键就是：

编译main.cpp时，编译器不知道f的实现，所以当碰到对它的调用时只是给出一个指示，指示连接器应该为它寻找f的实现体。这也就是说main.obj中没有关于f的任何一行二进制代码。

编译test.cpp时，编译器找到了f的实现。于是乎f的实现（二进制代码）出现在test.obj里。

连接时，连接器在test.obj中找到f的实现代码（二进制）的地址（通过符号导出表）。然后将main.obj中悬而未决的call XXX地址改成f实际的地址。完成。

再来看看函数模板的分离编译

对于函数模板，它的代码其实并不能直接编译成二进制代码，其中要有一个“实例化”的过程。举个例子：

也就是说，如果你在main.cpp文件中没有调用过f，f就得不到实例化，main.obj中也就没有关于f的任意一行二进制代码！如果你这样调用了：

这样main.obj中也就有了f<int>，f<double>两个函数的二进制代码段。以此类推。

但注意，函数模板被实例化的前提是编译器知道函数模板的定义。接下来我们看看把函数模板的定义与函数模板的声明给分离在两个文件中会发生什么。有人会说，不讲讲【把类模板的声明与定义分离在两个文件中会发生什么】吗？你这就是陷进去了，你仔细想想，类模板是没有声明与定义分离这一说的。

看下面函数模板的定义与声明分离的例子。

编译器在a.f()处并不知道A<int>类的成员函数f<int>()的定义，因为函数模板的定义不在test.h里面（注意类模板中的成员函数都是函数模板），于是编译器只好寄希望于连接器，希望它能够在其他.obj文件里面找到A<int>这个类的成员函数f()的代码，在本例中该.obj文件就是test.obj，然而，后者中真有A<int>类的成员函数f()的二进制代码吗？NO！！！因为C++标准明确表示，当一个模板不被用到的时侯它就不该被实例化出来，test.cpp中用到了A<int>::f了吗？没有！！所以实际上test.cpp编译出来的test.obj文件中一行关于A::f的二进制代码也没有，于是连接器就傻眼了，只好给出一个连接错误。

有人说我在main.cpp中实例化出A<int>了啊，为什么test.cpp里的函数模板不知道T是int呢？

前面说过了，在编译阶段，每个.cpp文件都是独立编译的，它们之间完全不会产生干扰。

那要怎么实例化test.cpp中的函数模板呢？（或者说怎样解决函数模板的声明与定义分离后导致的连接错误呢？）

方案一：如果在test.cpp中写一个函数，在函数中通过A<int>类的对象调用成员函数f()，则编译器会通过模板的定义将【A<int>类】和【A<int>类的成员函数f()】都实例化出来，因为在这个点上（test.cpp中），编译器知道类模板A的定义（#include了头文件），所以能够实例化出A<int>类，编译器也知道成员函数模板的定义，并且还调用了成员函数f()，所以能够实例化出成员函数f()，于是，test.obj的符号导出表中就有了A<int>::f这个符号的地址，于是连接器就能够将该地址填进main.obj中的符号导入表里，于是就能连接成功。特别注意，这里所说的实例化出A<int>类只表示能够将A类中所有带模板参数的成员变量全部实例化，不会将A类的所有成员函数模板全部实例化，对于成员函数模板，你通过A<int>类的对象调用了哪个成员函数，才会通过成员函数模板实例化出哪个成员函数。

方案二：在test.cpp中显示实例化该函数模板。格式为：template[函数返回类型][函数模板名]（函数参数列表），注意对于参数列表，是不用显示写this指针的类型的。在当前场景下就是【template void A<int>::f();】，有了这一行代码，编译器会在test.cpp中先实例化类模板A<int>，然后实例化成员函数模板f<int>，如下图所示。注意虽然我们说编译器会在test.cpp中先实例化类模板A<int>，但除了类模板中所有带模板参数的成员变量（下图中没有，这里我们假设有）和f<T>这一个成员函数模板被实例化了以外，其他所有的成员函数模板（下图中没有，这里我们假设有）都是不会被实例化的，因为没有template显示实例化其他成员函数模板。

有人肯定会说，现在类中只有一个成员函数模板f<T>，所以显示实例化很轻松，那要是我有100个成员函数模板，一个个去template也太麻烦了吧？所以这里还有更简便的第二种实例化的方法，就是不单独实例化某个成员函数模板，而是直接在test.cpp中显示实例化类模板，格式为【template A<int>;】，如下图红框处所示，类模板实例化出A<int>后，注意这里的类模板被实例化的含义和上一段不同，该类的所有成员函数包括f<int>()会全部自动被实例化出来。

上面两种方案虽然解决了【模板的声明与实现分离编译】产生的问题，但这两种方案有什么缺陷吗？

缺陷很明显，在其他文件cpp文件中，比如main.cpp中定义A<double>y，然后通过对象y调用函数y.f()时又会报连接错误，因为main.cpp中没有函数模板f<T>的实现代码，导致main.cpp中无法实例化出函数f<double>()，而test.cpp中也没有显示实例化出f<double>()，连接器当然找不到函数f<double>()，也就确认不了该函数的地址，最后报连接错误。解决方式：也只能靠我们手动显示实例化，从这也能看出，在test.cpp之外的其他.cpp文件中，每通过A<T>类模板实例化出一个类，我们都大概率要在test.cpp文件中也显示实例化一次f<T>()函数模板，这样就太不方便了，这就是缺陷。为什么说是大概率而不是绝对呢？因为如果main.cpp文件中没有通过【A<T>实例化出的类所定义的对象】调用f函数，我们就不必在test.cpp中显示实例化函数模板f<T>()。

而如果我们不将模板的声明与实现分离在两个文件中编译，全写在一个文件中，这样当类模板A<T>实例化时，成员函数模板f<T>()也就跟着实例化，直接就有了成员函数的定义，在编译阶段就直接确定了函数的地址，就不用连接器去找地址了。

对分离编译部分的总结

关键：在分离式编译的环境下，编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在，也不会去查找（当遇到未决符号时它会寄希望于连接器）。这种模式在没有模板的情况下运行良好，但遇到模板时就傻眼了，因为模板仅在需要的时候才会实例化出来，所以当编译器只看到函数模板的声明时，因为看不到函数模板的定义，所以它不能实例化该函数模板，只能创建一个具有外部连接的符号并期待连接器能够将符号的地址决议出来。然而当定义该函数模板的.cpp文件中没有用到该函数模板的实例时，编译器懒得去实例化，所以，整个工程的.obj中就找不到一行函数模板的实例的二进制代码，于是连接器也黔驴技穷了，最后就只能报一个连接错误。

看了上文，可以发现编写模板时，声明与定义分离是多么不便，所以最好不要分离它们。注意我们这里说的分离是指：函数模板的声明在.h文件，函数模板的定义在.cpp文件。这里我想说的是：虽然不建议将它们分离在不同文件里，但是建议将实现和声明分离在同一个.h文件中，实现放到类模板外，声明放到类模板里，这样方便看类模板的整体情况，因为如果类内部没有成员函数模板的实现，只有声明，就可以避免函数模板的实现的代码量过大导致看不清类模板的全貌。

模板中的typename

如上面代码编译会出错，因为编译器不能确定T::const_iterator是个类型，因为类中的静态变量和静态函数也是通过T::const_iterator这样的方式访问的。T::const_iterator被编译解析时有着逻辑上的矛盾：直到确定了T是什么东西，编译器才会知道T::const_iterator是不是一个类型；但当函数模板被编译解析时，T还是不确定的，这就导致了矛盾。有人说，那我通过函数模板实例化出一个函数，指定T是vector<int>，这样编译器就知道T::const_iterator是一个类型了。如果你这么想，那就是没分清先后顺序了，现在的问题是：因为模板的语法有问题，编译不通过，所以函数模板也就不存在，无法用该模板实例化出函数fun<vector<int>>。

那该怎么办呢？那有人又有奇思妙想，那我就特化出一个特化版本的函数模板，该函数模板指定了T是vector<int>。这样的确是可以的，如下图所示。

那有没有通用一点的、更加方便的方法呢？有，请继续往下看。

场景1

场景2

上面的场景1和场景2产生的错误是一样的，咱们以场景2为例子讲解。

因为在明确T之前、在函数模板实例化之前，完全没有办法来区分T::const_iterator是【一个类型】还是【一个类中的静态变量或者静态函数】，这绝对是滋生各种bug的温床，所以这时C++标准委员会再也忍不住了，与其到实例化时才能知道到底选择哪种方式来解释以上代码，还不如直接给出一个标准，标准是：对于在函数模板或者类模板中定义的依赖于模板参数的名称（或者叫标识符），只有在这个名称前使用了typename关键字来修饰，编译器才会将该名称当成是类型的名称，反之如果不加typename，编译器绝不会当它是一个类型，而是把他当作一个类中的静态变量或者是静态函数。

为此委员会决定引入一个新的关键字，这就是typename。这时如果你想直接告诉编译器T::const_iterator是一个类型，我们就可以通过typename，格式如：typename T::const_iterator，这样编译器就可以确定T::const_iterator是一个类型，而不再需要等到实例化时期才能确定，因此消除了前面提到的矛盾，最上面的无法通过编译的代码就能通过编译了，如下图所示。

所以总结一下：当你在类模板A外面使用一个类模板A中的内嵌类型B时（内嵌类型指的是：定义在类模板A中的内部类，或者是在类模板A中typedef重命名过的类），就需要在内嵌类型B的前面加typename。

前置声明（包括模板中的前置声明）

如下图，A类模板的定义在B类模板的下面，但B类模板中有A类模板的成员对象，此时就需要进行A类模板的前置声明。

说一下这个前置声明的几个注意事项。

第一，观察下面对比图，在类模板的前置声明的template<。。。>处和类模板的实现的template<。。。>处，只能有一个地方带有缺省参数，否则报错。对于不严格的编译器，如果在声明和定义处同时带有内置类型的缺省值一般只会有警告，而自定义类型则一定会报错；对于严格的编译器，则即使是内置类型，则也会报错。

第二，如下面对比图1所示，上半部分是正确的前置声明，下半部分只是把B类的template<。。。>语句给去掉了，然后就编译不通过，这是为什么呢？

首先解释为什么下图1的下半部分编译不通过。其原因是因为在B类上方只有A类模板的声明，而没有实现，这样会导致编译的时候，无法确定A类模板的大小，从而不能给对B类中A类对象进行分配空间。解决办法很简单，如下图2所示，第一种方法是把A类模板的实现放到B类上方；第二种方法是在B类中不要定义A类的对象成员，而是定义A类对象的指针成员或者引用成员。

（说一下，上一段的内容在非模板的情况中也同样适用，如下图3所示，出错原因和解决办法都与上一段中的相同）

然后解释为什么下图1的上半部分只是加了一行template<，，，>就能够通过编译。给B加上template<，，，>后，B就成为了类模板，这样的话，只有在创建B类型对象的时候，才会通过B类模板实例化出具体的B类，才会需要确定A类模板的大小从而给B类中的A类对象进行分配空间，也就是说此时B类模板的实现这里相当于B类模板的声明，不需要确定A类模板的大小给B类中的A类对象进行分配空间，所以编译就能顺利的继续向下走，等到后序在主函数中真有需要创建B类型对象的时候，A类模板早就被编译扫描过了，A类模板的大小也就明了了，此时就不会出错了。从这就能得到一个启示，从前置声明到某个类A的路程中，中间不能在非模板的类中或者函数中定义A类的对象，只能定义A类对象的指针或者引用，否则就会报错（当然如果是模板，则可以定义A类的对象）。