核心内容摘要
探索“操”之奥秘：一种深入骨髓的联结与共鸣
《你真的了解C吗》No.034类模板与函数模板的差异——推导的权力边界导言不对等的待遇在 C03 中你会发现一个奇怪的现象当你调用std::make_pair(1,
2.
时你不需要写int, double编译器自己就能推导出来。
但当你定义std::pair对象时你必须写成std::pairint, double p(1,
2.
;。
这种差异源于函数和类在 C 语法体系中完全不同的推导逻辑和查找机制。
函数模板参数推导Template Argument Deduction函数模板的初衷是泛型算法。
为了让算法用起来和普通函数一样自然编译器被授予了“观察参数”的权力。
自动推导编译器查看你传入的实参Arguments反推模板形参Parameters。
函数重载解析函数模板可以和普通函数、其他模板函数构成重载集。
编译器通过 SFINAENo.033和匹配程度来筛选最合适的版本。
类模板显式化的枷锁在 C03 标准中类模板不支持参数推导。
你必须显式提供所有模板参数。
物理理由构造函数的模糊性一个类可以有多个构造函数。
如果允许推导编译器可能无法确定该根据哪个构造函数来决定类的类型。
特化歧义类模板存在偏特化No.032。
推导过程中如果同时匹配了多个特化版本类内部的成员布局Memory Layout会完全不同。
编译器为了保证类型系统的严谨性在 C03 阶段选择了“拒绝推导”。
工业界的绕路没有 auto 时的“Make 系列”注意C03 没有类型推导关键字auto。
那么既然没有auto为什么我们还需要make_pair这种辅助函数如果还是要写类型声明直接构造对象不就好了吗真相是辅助函数是为了在“临时对象”和“嵌套模板”中减负。
// 假设我们要调用一个接收 pair 的函数voidprocess(std::pairint,doublep);// 方案 A显式构造代码冗长process(std::pairint,double(1,
2.
);// 方案 B利用 make_pair 推导代码简洁// 编译器通过 make_pair 的参数自动推导出 T1int, T2double// 返回一个临时的 std::pairint, doubleprocess(std::make_pair(1,
2.
);在没有auto的年代make_pair的
核心价值在于避免在传递临时变量时重复书写复杂的模板参数尤其当模板嵌套很深时如std::vectorstd::pairint, int 这种简写能显著降低代码的视觉噪点。
为什么 C03 严禁函数模板默认参数这是一个非常深刻的设计决策。
类模板可以写template typename T int class Box;但函数模板在 C03 里绝对不行。
原因重载解析Overload Resolution的复杂性。
函数是可以重载的类不行编译器在查找函数时需要根据参数去匹配最合适的版本。
如果允许函数模板有默认类型会产生巨大的歧义。
推导冲突// 假设 C03 允许默认参数实际上禁止templatetypenameTintvoidfunc(T t);func(
3.
;// 此时 T 应该推导为 double 还是使用默认的 int在 C03 的设计哲学中函数模板的类型应该完全由参数决定或者完全显式指定。
引入默认参数会使得“推导结果”与“默认设定”发生冲突导致重载解析算法变得异常脆弱且难以预测。
为了保证编译器的稳定性这一特性直到 C11 重新梳理了重载规则后才被有条件地放开。
总结算法与结构的平衡函数模板侧重于行为通过参数推导追求调用的简洁但严禁默认参数以维持重载解析的纯净。
类模板侧重于结构通过显式指定确保类型系统的绝对安全允许默认参数以提高复用性。
C03 准则即便没有automake_xxx依然是处理临时对象、减少参数冗余的神器。
下一篇预告在模板内部如果你引用了一个依赖于模板参数的类型比如T::value_type编译器有时会报错说它看不懂。
这时候你必须祭出一个神秘的关键字。
➡️《你真的了解C吗》No.035typename 的谜团——从属类型名。