《你真的了解C++吗》No.034：类模板与函数模板的差异——推导的权力边界

《你真的了解C++吗》No.034：类模板与函数模板的差异——推导的权力边界

导言：不对等的待遇

在 C++03 中，你会发现一个奇怪的现象：

• 当你调用std::make_pair(1, 2.0)时，你不需要写<int, double>，编译器自己就能推导出来。
• 但当你定义std::pair对象时，你必须写成std::pair<int, double> p(1, 2.0);。

这种差异源于函数和类在 C++ 语法体系中完全不同的推导逻辑和查找机制。

一、 函数模板：参数推导（Template Argument Deduction）

函数模板的初衷是泛型算法。为了让算法用起来和普通函数一样自然，编译器被授予了“观察参数”的权力。

1. 自动推导：编译器查看你传入的实参（Arguments），反推模板形参（Parameters）。
2. 函数重载解析：函数模板可以和普通函数、其他模板函数构成重载集。编译器通过 SFINAE（No.033）和匹配程度来筛选最合适的版本。

二、 类模板：显式化的枷锁

在 C++03 标准中，类模板不支持参数推导。你必须显式提供所有模板参数。

物理理由：

1. 构造函数的模糊性：一个类可以有多个构造函数。如果允许推导，编译器可能无法确定该根据哪个构造函数来决定类的类型。
2. 特化歧义：类模板存在偏特化（No.032）。推导过程中，如果同时匹配了多个特化版本，类内部的成员布局（Memory Layout）会完全不同。编译器为了保证类型系统的严谨性，在 C++03 阶段选择了“拒绝推导”。

三、 工业界的绕路：没有 auto 时的“Make 系列”

注意：C++03 没有类型推导关键字auto。那么，既然没有auto，为什么我们还需要make_pair这种辅助函数？如果还是要写类型声明，直接构造对象不就好了吗？

真相是：辅助函数是为了在“临时对象”和“嵌套模板”中减负。

// 假设我们要调用一个接收 pair 的函数voidprocess(std::pair<int,double>p);// 方案 A：显式构造（代码冗长）process(std::pair<int,double>(1,2.2));// 方案 B：利用 make_pair 推导（代码简洁）// 编译器通过 make_pair 的参数自动推导出 T1=int, T2=double// 返回一个临时的 std::pair<int, double>process(std::make_pair(1,2.2));

在没有auto的年代，make_pair的核心价值在于避免在传递临时变量时重复书写复杂的模板参数，尤其当模板嵌套很深时（如std::vector<std::pair<int, int> >），这种简写能显著降低代码的视觉噪点。

四、 为什么 C++03 严禁函数模板默认参数？

这是一个非常深刻的设计决策。类模板可以写template <typename T = int> class Box;，但函数模板在 C++03 里绝对不行。

原因：重载解析（Overload Resolution）的复杂性。

1. 函数是可以重载的，类不行：
   编译器在查找函数时，需要根据参数去匹配最合适的版本。如果允许函数模板有默认类型，会产生巨大的歧义。
2. 推导冲突：

// 假设 C++03 允许默认参数（实际上禁止）template<typenameT=int>voidfunc(T t);func(3.14);// 此时 T 应该推导为 double 还是使用默认的 int？

在 C++03 的设计哲学中，函数模板的类型应该完全由参数决定或者完全显式指定。引入默认参数会使得“推导结果”与“默认设定”发生冲突，导致重载解析算法变得异常脆弱且难以预测。为了保证编译器的稳定性，这一特性直到 C++11 重新梳理了重载规则后才被有条件地放开。

总结：算法与结构的平衡

• 函数模板：侧重于行为，通过参数推导追求调用的简洁，但严禁默认参数以维持重载解析的纯净。
• 类模板：侧重于结构，通过显式指定确保类型系统的绝对安全，允许默认参数以提高复用性。
• C++03 准则：即便没有auto，make_xxx依然是处理临时对象、减少参数冗余的神器。

下一篇预告：在模板内部，如果你引用了一个依赖于模板参数的类型（比如T::value_type），编译器有时会报错说它看不懂。这时候，你必须祭出一个神秘的关键字。

➡️《你真的了解C++吗》No.035：typename 的谜团——从属类型名。