如果你写数值计算相关的代码大概率写过a b c这种向量表达式。在朴素实现里这行代码背后是两次临时对象创建、两次堆内存分配、三轮数据遍历表达式模板Expression Templates要解决的恰恰就是这个看起来不起眼的性能问题。我第一次接触这个技术是在研究 Eigen 源码的时候后来自己也手写过一套最小实现放到点云处理项目里收益和坑都非常直观。这篇文章会把问题讲透从零写一个能用的表达式模板再把实际工程中的经验和避坑清单一起整理出来适合被数值计算性能折磨的开发者也适合想找模板元编程完整案例的进阶学习者。1. 问题缘起运算符重载的性能陷阱1.1 一次加法背后的三次分配假设你有一个最普通的向量类Vec里面是double*加长度operator的定义大概是这样的Vec operator(const Vec other) const { Vec tmp(size()); for (size_t i 0; i size(); i) tmp[i] data_[i] other[i]; return tmp; }这套代码逻辑完全没问题但当你写下Vec d a b c;的时候实际发生的事是先执行a b新建一个临时数组把结果逐元素写进去再拿这个临时数组和c做加法又新建一个临时数组。如果编译器开启了 C11 的移动语义临时对象之间的深层拷贝会被优化掉但堆分配和遍历一次都没少。你可以想象成抄写一份几百页的文件每加一行内容就把整份文件重新抄一遍——这种浪费在数据规模变大以后会非常明显。表达式模板的思路完全相反operator不立刻计算结果而是返回一个“记录运算的轻量级对象”。真正求值推迟到最后赋值给Vec的时候才发生而且整个过程只遍历一次数据。这也是我开头为什么说它是一个把“运行时逐次计算”变成“编译期构建计算计划”的技术。1.2 临时对象真正的成本在哪里很多初学者会觉得移动语义都出来这么多年了临时对象还有什么成本这里的关键点在于移动确实解决了“拷贝数据”的开销但没有解决“分配内存”和“遍历数据”的开销。每生成一个临时Vec都意味着一次new double[N]而堆分配本身是要走内存分配器、可能触发系统调用、最终还要delete[]的。我做过一个很简单的对比实验N 1,000,000表达式是a b c。朴素实现的耗时大概是表达式模板的三倍左右其中大部分差距来自两次临时数组的构造与析构。随着 N 继续增大差距会更明显因为每次遍历都是一整轮缓存读写数据量一旦超过 cache 容量就是几百毫秒甚至秒级的差别。做图形学、数值模拟、机器学习这类核心循环的人对这种开销尤其敏感。1.3 哪些场景才真正值得用表达式模板这个技术不是万金油我用它之前会先判断场景。适合用的情况很明确操作数是密集数组或矩阵表达式链比较长且代码在性能关键路径上。你写一个光线追踪器、求解偏微分方程、做张量运算这些都是典型场景。表达式模板能让你写出接近数学表达式的代码同时保留手写循环的性能。不适合的情况也同样明确如果表达式很短、调用频率低、或者数据规模小到一次遍历只要几百纳秒那为了表达式模板付出的编译时间和代码复杂度就不划算了。另外如果某个表达式需要被保存下来跨语句反复使用那要格外小心悬垂引用的问题后面我会专门讲这个坑。对比维度朴素运算符重载表达式模板表达式链abc2 次临时对象、2 次堆分配0 次堆分配数据遍历次数3 轮1 轮表达式保存复用结果固定有悬垂引用风险编译时间低明显增加运行时性能较差可与手写循环媲美2. 核心设计思想编译期构建表达式运行期一次求值2.1 CRTP把接口静态化看到表达式模板的代码第一印象往往是一堆莫名其妙的模板继承比如struct Add : ExprBaseAddL, R。这种写法叫 CRTPCuriously Recurring Template Pattern奇异递归模板模式它解决的核心问题是“如何在不使用虚函数的前提下让不同类型的表达式拥有统一接口”。你可能会想为什么不给表达式节点定义一个抽象基类然后用虚函数答案很现实虚函数调用有额外开销更重要的是它会阻碍编译器内联。如果operator[]是虚函数编译器在求值循环里就无法确定到底调用哪个实现也就没法展开递归、没法做向量化。CRTP 通过把派生类类型作为模板参数传给基类让基类的接口函数直接static_cast成派生类再调用对应方法整个过程在编译期就已经确定连一层函数调用开销都没有。2.2 表达式树与延迟求值a b c经过表达式模板的operator之后会变成一个嵌套的类型AddAddVec, Vec, Vec。你可以把它看作一棵编译期构造的表达式树根节点是最后一次加法左孩子是第一次加法右孩子是c。每个节点只持有操作数的引用不持有任何计算结果。这样一来表达式对象本身就是一个“计算计划”而不是“计算结果”。我这里喜欢用一个点餐的类比朴素实现是每点一道菜后厨立刻做一道菜端上来表达式模板则是把整张菜单写完然后一次性把所有菜做出来。前者过程直观后者在大批量场景下效率更高。延迟求值带来的收益不仅仅是省几次遍历还让编译器能够看到完整的计算链从而把多层嵌套的函数调用全部内联展开甚至把最终循环优化成 SIMD 向量化指令。2.3 零临时对象是怎么来的表达式模板里也有临时对象——每次operator返回的Add节点就是一个临时对象。但它和Vec临时对象有本质区别Add节点里只有两个引用和一个操作类型通常几十个字节就能承载完全不需要堆分配甚至大部分时候活在寄存器里。真正的数据数组一个都没新建这才是“零临时对象”说法的准确含义。提示表达式模板优化的核心是消除“中间数组的分配与遍历”不是消除所有临时对象。搞清楚这点你就不会在看完代码后困惑“这不是还有临时对象吗”。3. 手写一个最小可用的表达式模板3.1 设计取舍先行在动手写代码之前先说清楚我为什么选择这套最小设计。我见过很多教程一上来就堆 traits、分发器、类型标签那确实能应付生产环境但初学者很容易被淹没。这里我采用 CRTP 基类定义接口、两个表达式节点加法和标量乘法、一个向量类足够展示核心原理又不至于让代码失去控制。生产级实现可以在这个基础上逐步加东西后面我会列改进方向。关键词是“最小但完整”确保每个环节都能讲明白。你理解了这套骨架之后再去读 Eigen 源码就不会那么吃力了。3.2 完整代码与关键点解释下面是完整实现我直接贴出来然后逐段解释#include cstddef #include new // 表达式基类CRTP 静态接口 template typename Expr struct ExprBase { std::size_t size() const { return static_castconst Expr(*this).size(); } double operator[](std::size_t i) const { return static_castconst Expr(*this)[i]; } }; // 加法表达式节点 template typename L, typename R struct Add : ExprBaseAddL, R { const L lhs; const R rhs; Add(const L l, const R r) : lhs(l), rhs(r) {} std::size_t size() const { return lhs.size(); } double operator[](std::size_t i) const { return lhs[i] rhs[i]; } }; // 标量乘法表达式节点 template typename L struct ScalarMul : ExprBaseScalarMulL { const L lhs; double s; ScalarMul(const L l, double v) : lhs(l), s(v) {} std::size_t size() const { return lhs.size(); } double operator[](std::size_t i) const { return lhs[i] * s; } }; // 向量类 class Vec : public ExprBaseVec { std::size_t n_; double* data_; public: explicit Vec(std::size_t n) : n_(n), data_(new double[n]) {} Vec(const Vec other) : n_(other.n_), data_(new double[n_]) { for (std::size_t i 0; i n_; i) data_[i] other.data_[i]; } // 从任意表达式构造真正求值发生在这里 template typename Expr Vec(const ExprBaseExpr expr) : n_(expr.size()), data_(new double[n_]) { for (std::size_t i 0; i n_; i) data_[i] expr[i]; } Vec operator(const Vec other) { if (this ! other) { if (n_ ! other.n_) { delete[] data_; n_ other.n_; data_ new double[n_]; } for (std::size_t i 0; i n_; i) data_[i] other.data_[i]; } return *this; } template typename Expr Vec operator(const ExprBaseExpr expr) { if (n_ ! expr.size()) { delete[] data_; n_ expr.size(); data_ new double[n_]; } for (std::size_t i 0; i n_; i) data_[i] expr[i]; return *this; } ~Vec() { delete[] data_; } double operator[](std::size_t i) const { return data_[i]; } double operator[](std::size_t i) { return data_[i]; } std::size_t size() const { return n_; } }; // 运算符重载返回表达式节点不计算结果 template typename L, typename R AddL, R operator(const ExprBaseL l, const ExprBaseR r) { return AddL, R(static_castconst L(l), static_castconst R(r)); } template typename L ScalarMulL operator*(const ExprBaseL l, double s) { return ScalarMulL(static_castconst L(l), s); }ExprBase是整个机制的枢纽。Vec继承ExprBaseVec表达式节点继承各自的ExprBaseAdd...于是所有参与运算的类型都统一到了ExprBaseX这个门面之下operator才能用一个模板覆盖所有组合。关键触发点是Vec的模板构造函数和模板赋值运算符。Vec d a b c;会先通过重载决议找到operator构造出一个AddAddVec, Vec, Vec临时对象然后匹配到Vec的模板构造函数。此时循环里调用expr[i]实际上是一连串内联递归先计算a[i] b[i]的结果再加上c[i]整个过程只遍历一次数据数组。这就是和朴素实现最大的区别编译器看到的是一条完整流水线而不是分别在三个独立循环里干活。有一个细节需要提醒你由于Vec本身也继承自ExprBaseVecVec c a;这种代码有可能匹配到模板构造函数而不是拷贝构造。结果通常是对的因为它会逐元素复制但语义上绕过了拷贝构造。严谨的做法是用std::enable_if或者专门的 traits 判断Expr是不是Vec类型把模板构造函数限制为只接受真正的表达式节点。我在实际项目中第一次用的时候没注意这点后来查一个看似“多余”的拷贝才发现。3.3 性能实测对比与结论如果你要亲自验证性能我建议用一个简单的场景N 1000000计算d a b c循环跑 100 次取平均值。朴素实现里operator每次调用都会新建数组表达式模板实现里d的构造只是一次遍历。在我本机X86-64-O3的实测结果大致是朴素版本约 38ms表达式模板约 12ms。差距主要来自两次堆分配和额外的两轮遍历。如果你把表达式改成(a b) * 2.0 c表达式模板的优势会更加明显因为标量乘法节点几乎不增加任何成本而朴素实现会多出至少一个临时数组。还有一个关于优化的心得务必在开启优化的情况下测试比如至少-O2。在-O0下模板代码往往因为不内联而变得更慢于是你会得出“表达式模板没用”的错误结论。我见过不止一个同事在调试模式下评估性能然后直接把这个技术否掉。3.4 这一步还能怎么改进这套骨架最大的问题是没有做尺寸一致性检查。如果a和c的长度不一样Add::size()会取a的长度然后求值时越界访问c崩溃得很没品位。生产代码里应该在表达式节点里加一个断言比如assert(lhs.size() rhs.size())或者在最终赋值时用static_assert配合类型信息做编译期检查。内存管理上真实项目里建议改用std::vectordouble或std::spandouble来持有数据能少写很多析构和拷贝代码。还应该扩展更多运算节点比如减法、除法、内积、逐元素乘等。等你把常见的运算都补完了会发现代码模式高度统一每个节点就是“持有若干操作数引用 一个 size 一个 operator[]”这也是为什么表达式模板很容易用宏或代码生成工具批量产出。4. 进阶表达式模板在真实数值库中的形态4.1 混合标量与向量运算表达式模板最被低估的一点是它完全不破坏运算符优先级。Vec e a * 2.0 b;会被正常解析为(a * 2.0) b然后被翻译成AddScalarMulVec, Vec。标量2.0被折叠进节点内部不需要任何额外临时对象。当你把两种不同的节点组合在一起时CRTP 的静态分发依然能精确工作。比如(a b) * 2.0最后的节点类型是ScalarMulAddVec, Vec。这种嵌套在代码里看起来复杂但编译器处理得很好因为它只是类型层面的递归没有虚函数、没有运行时间接跳转。在我实际写过的点云滤波代码里经常出现out (cloud - mean) * weight offset这样的表达式。一个完整的表达式模板实现能把多个步骤融合成一次遍历这对几十万点的点云处理影响非常大。4.2 惰性求值和求值策略的博弈惰性求值是双刃剑我在这里吃过亏。假设你写了auto expr a b; a[0] 100.0; Vec d expr;由于expr持有的是a的引用最终的d会使用修改后的a[0]而不是表达式创建时的值。这在很多业务逻辑里是反直觉的你保存了一个表达式以为它定格了当时的计算结果实际上它只是个指向数据的计算计划。更麻烦的是对同一表达式求值多次的场景。Expr对象每次被转成Vec就会完整遍历一次如果你在一个循环里反复用它性能可能比朴素实现还差。这也是为什么 Eigen 内部对矩阵乘法这类高成本运算通常采用 eager evaluation求值缓存而对逐元素运算才放心使用 lazy evaluation。理解这个权衡很重要表达式模板不是“永远延迟计算更好”而是“在合适的时候延迟、在合适的时候立即算”。4.3 真实案例Eigen 的用法与权衡如果你去读 Eigen 的源码会发现整个库几乎是由表达式模板堆起来的。mat1 mat2 * mat3最终会生成一个极其复杂的表达式类型里面包含了矩阵乘法、加法、缓存策略、向量化分支等大量细节。你根本不会去手动写出这个类型名通常用auto或直接赋值给MatrixXd就好。Eigen 的实践给我的启发是表达式模板可以做成一个对外几乎透明的层。使用者写的代码和朴素版本一模一样性能却接近手写循环。它真正的成本在编译期——复杂表达式会让模板实例数量暴增编译时间从几秒涨到几十秒是常事。如果你维护一个构建时间敏感的中间层需要对表达式模板的使用范围做一些控制比如把公共的复杂表达式封装成具名函数降低每个编译单元的压力。4.4 编译期优化后发生了什么当编译器拿到AddAddVec, Vec, Vec的求值循环时它能看到完整的调用链expr[i]调用Add::operator[]里面又调用Add::operator[]和Vec::operator[]这些全部是内联的。于是循环体被展开成简单的a[i] b[i] c[i]编译器可以顺理成章地自动向量化生成 SIMD 指令大幅度提高计算密度。到了这一步你写的数学表达式和手写的高性能循环在汇编层面已经非常接近了。这也是为什么我会反复强调表达式模板是一门“把抽象成本降到零”的技术。它让代码保持可读性同时不牺牲底层控制能力。如果你需要极致的调优甚至可以基于表达式树结构在编译期做更多变换比如自动识别a * 1.0并把它优化掉或者把连续的加法链重组以减少指令依赖。5. 常见问题、坑位盘点与排查技巧5.1 悬垂引用表达式模板中最隐蔽的坑表达式节点保存的是引用那就意味着被引用的对象生命周期必须覆盖到求值完成之后。下面这样的代码是典型事故现场Vec make_sum(const Vec x, const Vec y) { return x y; // 返回表达式节点其中引用指向 x 和 y }如果调用Vec d make_sum(a, b);由于函数返回的是临时表达式节点而节点的引用指向a和b只要a、b在函数返回后还活着这次求值没问题。但如果你写成Vec d (Vec(100) a); // 左操作数是临时 Vec表达式求值发生在这一整行结束之前临时Vec还活着所以安全。真正的危险是你把表达式节点存起来auto expr a b;然后让a离开作用域再用expr。此时引用指向已经销毁的数据轻则结果错误重则直接段错误。注意表达式模板对象一定要按临时量使用。除非你极其清楚生命周期否则不要把它长期保存更不要跨函数传递。5.2 编译错误信息又长又乱怎么破表达式模板的编译错误是出了名的劝退。你少写一个const编译器可能报出几十行嵌套模板类型看上去像是天书。我的经验是先看错误信息的第一行它通常指明了哪个函数或哪个类型无法匹配再用static_assert做前置检查比如在Vec构造函数里加一句尺寸一致的断言让错误更早、更友好地被捕获。另一个实用技巧是想办法把模板类型打印出来。C 里可以用一个故意的编译失败强制编译器显示类型template typename T struct TypePrinter; TypePrinterdecltype(expr) tp; // 编译器会报出 expr 的完整类型C20 之后还可以用 concept 对表达式类型做约束错误信息会清晰很多。比如定义template typename T concept Expression requires(T t) { t.size(); t[0]; };然后让运算符只接受满足该 concept 的参数。5.3 性能不升反降怎么办我用表达式模板踩过的最大的坑是忘记开优化。默认的-O0下模板代码膨胀和内联失败会让性能比朴素实现更差。这不算技术问题而是评估方式问题。其次如果你保存表达式并多次求值惰性求值的优势会变成劣势这时候要么改成 eager 缓存要么就别用表达式模板。另外如果单个元素的计算本身很复杂比如包含函数调用、分支和查找表表达式融合带来的收益会被单次计算的成本稀释这时候不如老老实实写循环。定位性能问题我一般靠两样东西perf stat看指令数和缓存命中率perf record加火焰图看热点。表达式模板如果正常工作热点应该集中在求值循环本身而不是new和delete。如果你看到大量分配相关的调用说明表达式没有真正被融合多半是某个环节不小心返回了具体对象而不是表达式节点。5.4 实践中的速查表症状原因排查思路结果错误且随机悬垂引用检查所有表达式节点的引用生命周期编译报错几百行类型不匹配或缺少 const看第一行错误用 TypePrinter 打印类型性能反而更差未开优化、多次求值同一表达式确认 -O2 以上避免保存表达式复用崩溃在 operator[]尺寸不一致在节点里加 assert统一入口检查debug 下正常 release 崩依赖了未定义行为重点检查悬垂引用和越界访问说实话表达式模板是我在 C 里见过“收益和代价都极其鲜明”的技术。它能让数值代码的抽象层次提升一大截写的每一条运算都接近数学公式跑起来却和手写循环差不多快但代价是编译时间变长、错误信息变烂、生命周期必须小心翼翼。我最后分享一个经验不要一上来就在大型项目里全量引入表达式模板。先拿一个百行规模的向量类当试验田实现一次a b c亲手对比性能亲手体会模板类型展开的过程。等你能顺畅地读懂AddAddVec, Vec, Vec时再考虑把它用到真正的性能热点。这个节奏我在多个项目里验证过稳。 
长河君 · 2026/10/10 13:39:02 · 阅读 1.2k C++表达式模板：从零实现零开销数值计算的性能优化
如果你写数值计算相关的代码大概率写过a b c这种向量表达式。在朴素实现里这行代码背后是两次临时对象创建、两次堆内存分配、三轮数据遍历表达式模板Expression Templates要解决的恰恰就是这个看起来不起眼的性能问题。我第一次接触这个技术是在研究 Eigen 源码的时候后来自己也手写过一套最小实现放到点云处理项目里收益和坑都非常直观。这篇文章会把问题讲透从零写一个能用的表达式模板再把实际工程中的经验和避坑清单一起整理出来适合被数值计算性能折磨的开发者也适合想找模板元编程完整案例的进阶学习者。1. 问题缘起运算符重载的性能陷阱1.1 一次加法背后的三次分配假设你有一个最普通的向量类Vec里面是double*加长度operator的定义大概是这样的Vec operator(const Vec other) const { Vec tmp(size()); for (size_t i 0; i size(); i) tmp[i] data_[i] other[i]; return tmp; }这套代码逻辑完全没问题但当你写下Vec d a b c;的时候实际发生的事是先执行a b新建一个临时数组把结果逐元素写进去再拿这个临时数组和c做加法又新建一个临时数组。如果编译器开启了 C11 的移动语义临时对象之间的深层拷贝会被优化掉但堆分配和遍历一次都没少。你可以想象成抄写一份几百页的文件每加一行内容就把整份文件重新抄一遍——这种浪费在数据规模变大以后会非常明显。表达式模板的思路完全相反operator不立刻计算结果而是返回一个“记录运算的轻量级对象”。真正求值推迟到最后赋值给Vec的时候才发生而且整个过程只遍历一次数据。这也是我开头为什么说它是一个把“运行时逐次计算”变成“编译期构建计算计划”的技术。1.2 临时对象真正的成本在哪里很多初学者会觉得移动语义都出来这么多年了临时对象还有什么成本这里的关键点在于移动确实解决了“拷贝数据”的开销但没有解决“分配内存”和“遍历数据”的开销。每生成一个临时Vec都意味着一次new double[N]而堆分配本身是要走内存分配器、可能触发系统调用、最终还要delete[]的。我做过一个很简单的对比实验N 1,000,000表达式是a b c。朴素实现的耗时大概是表达式模板的三倍左右其中大部分差距来自两次临时数组的构造与析构。随着 N 继续增大差距会更明显因为每次遍历都是一整轮缓存读写数据量一旦超过 cache 容量就是几百毫秒甚至秒级的差别。做图形学、数值模拟、机器学习这类核心循环的人对这种开销尤其敏感。1.3 哪些场景才真正值得用表达式模板这个技术不是万金油我用它之前会先判断场景。适合用的情况很明确操作数是密集数组或矩阵表达式链比较长且代码在性能关键路径上。你写一个光线追踪器、求解偏微分方程、做张量运算这些都是典型场景。表达式模板能让你写出接近数学表达式的代码同时保留手写循环的性能。不适合的情况也同样明确如果表达式很短、调用频率低、或者数据规模小到一次遍历只要几百纳秒那为了表达式模板付出的编译时间和代码复杂度就不划算了。另外如果某个表达式需要被保存下来跨语句反复使用那要格外小心悬垂引用的问题后面我会专门讲这个坑。对比维度朴素运算符重载表达式模板表达式链abc2 次临时对象、2 次堆分配0 次堆分配数据遍历次数3 轮1 轮表达式保存复用结果固定有悬垂引用风险编译时间低明显增加运行时性能较差可与手写循环媲美2. 核心设计思想编译期构建表达式运行期一次求值2.1 CRTP把接口静态化看到表达式模板的代码第一印象往往是一堆莫名其妙的模板继承比如struct Add : ExprBaseAddL, R。这种写法叫 CRTPCuriously Recurring Template Pattern奇异递归模板模式它解决的核心问题是“如何在不使用虚函数的前提下让不同类型的表达式拥有统一接口”。你可能会想为什么不给表达式节点定义一个抽象基类然后用虚函数答案很现实虚函数调用有额外开销更重要的是它会阻碍编译器内联。如果operator[]是虚函数编译器在求值循环里就无法确定到底调用哪个实现也就没法展开递归、没法做向量化。CRTP 通过把派生类类型作为模板参数传给基类让基类的接口函数直接static_cast成派生类再调用对应方法整个过程在编译期就已经确定连一层函数调用开销都没有。2.2 表达式树与延迟求值a b c经过表达式模板的operator之后会变成一个嵌套的类型AddAddVec, Vec, Vec。你可以把它看作一棵编译期构造的表达式树根节点是最后一次加法左孩子是第一次加法右孩子是c。每个节点只持有操作数的引用不持有任何计算结果。这样一来表达式对象本身就是一个“计算计划”而不是“计算结果”。我这里喜欢用一个点餐的类比朴素实现是每点一道菜后厨立刻做一道菜端上来表达式模板则是把整张菜单写完然后一次性把所有菜做出来。前者过程直观后者在大批量场景下效率更高。延迟求值带来的收益不仅仅是省几次遍历还让编译器能够看到完整的计算链从而把多层嵌套的函数调用全部内联展开甚至把最终循环优化成 SIMD 向量化指令。2.3 零临时对象是怎么来的表达式模板里也有临时对象——每次operator返回的Add节点就是一个临时对象。但它和Vec临时对象有本质区别Add节点里只有两个引用和一个操作类型通常几十个字节就能承载完全不需要堆分配甚至大部分时候活在寄存器里。真正的数据数组一个都没新建这才是“零临时对象”说法的准确含义。提示表达式模板优化的核心是消除“中间数组的分配与遍历”不是消除所有临时对象。搞清楚这点你就不会在看完代码后困惑“这不是还有临时对象吗”。3. 手写一个最小可用的表达式模板3.1 设计取舍先行在动手写代码之前先说清楚我为什么选择这套最小设计。我见过很多教程一上来就堆 traits、分发器、类型标签那确实能应付生产环境但初学者很容易被淹没。这里我采用 CRTP 基类定义接口、两个表达式节点加法和标量乘法、一个向量类足够展示核心原理又不至于让代码失去控制。生产级实现可以在这个基础上逐步加东西后面我会列改进方向。关键词是“最小但完整”确保每个环节都能讲明白。你理解了这套骨架之后再去读 Eigen 源码就不会那么吃力了。3.2 完整代码与关键点解释下面是完整实现我直接贴出来然后逐段解释#include cstddef #include new // 表达式基类CRTP 静态接口 template typename Expr struct ExprBase { std::size_t size() const { return static_castconst Expr(*this).size(); } double operator[](std::size_t i) const { return static_castconst Expr(*this)[i]; } }; // 加法表达式节点 template typename L, typename R struct Add : ExprBaseAddL, R { const L lhs; const R rhs; Add(const L l, const R r) : lhs(l), rhs(r) {} std::size_t size() const { return lhs.size(); } double operator[](std::size_t i) const { return lhs[i] rhs[i]; } }; // 标量乘法表达式节点 template typename L struct ScalarMul : ExprBaseScalarMulL { const L lhs; double s; ScalarMul(const L l, double v) : lhs(l), s(v) {} std::size_t size() const { return lhs.size(); } double operator[](std::size_t i) const { return lhs[i] * s; } }; // 向量类 class Vec : public ExprBaseVec { std::size_t n_; double* data_; public: explicit Vec(std::size_t n) : n_(n), data_(new double[n]) {} Vec(const Vec other) : n_(other.n_), data_(new double[n_]) { for (std::size_t i 0; i n_; i) data_[i] other.data_[i]; } // 从任意表达式构造真正求值发生在这里 template typename Expr Vec(const ExprBaseExpr expr) : n_(expr.size()), data_(new double[n_]) { for (std::size_t i 0; i n_; i) data_[i] expr[i]; } Vec operator(const Vec other) { if (this ! other) { if (n_ ! other.n_) { delete[] data_; n_ other.n_; data_ new double[n_]; } for (std::size_t i 0; i n_; i) data_[i] other.data_[i]; } return *this; } template typename Expr Vec operator(const ExprBaseExpr expr) { if (n_ ! expr.size()) { delete[] data_; n_ expr.size(); data_ new double[n_]; } for (std::size_t i 0; i n_; i) data_[i] expr[i]; return *this; } ~Vec() { delete[] data_; } double operator[](std::size_t i) const { return data_[i]; } double operator[](std::size_t i) { return data_[i]; } std::size_t size() const { return n_; } }; // 运算符重载返回表达式节点不计算结果 template typename L, typename R AddL, R operator(const ExprBaseL l, const ExprBaseR r) { return AddL, R(static_castconst L(l), static_castconst R(r)); } template typename L ScalarMulL operator*(const ExprBaseL l, double s) { return ScalarMulL(static_castconst L(l), s); }ExprBase是整个机制的枢纽。Vec继承ExprBaseVec表达式节点继承各自的ExprBaseAdd...于是所有参与运算的类型都统一到了ExprBaseX这个门面之下operator才能用一个模板覆盖所有组合。关键触发点是Vec的模板构造函数和模板赋值运算符。Vec d a b c;会先通过重载决议找到operator构造出一个AddAddVec, Vec, Vec临时对象然后匹配到Vec的模板构造函数。此时循环里调用expr[i]实际上是一连串内联递归先计算a[i] b[i]的结果再加上c[i]整个过程只遍历一次数据数组。这就是和朴素实现最大的区别编译器看到的是一条完整流水线而不是分别在三个独立循环里干活。有一个细节需要提醒你由于Vec本身也继承自ExprBaseVecVec c a;这种代码有可能匹配到模板构造函数而不是拷贝构造。结果通常是对的因为它会逐元素复制但语义上绕过了拷贝构造。严谨的做法是用std::enable_if或者专门的 traits 判断Expr是不是Vec类型把模板构造函数限制为只接受真正的表达式节点。我在实际项目中第一次用的时候没注意这点后来查一个看似“多余”的拷贝才发现。3.3 性能实测对比与结论如果你要亲自验证性能我建议用一个简单的场景N 1000000计算d a b c循环跑 100 次取平均值。朴素实现里operator每次调用都会新建数组表达式模板实现里d的构造只是一次遍历。在我本机X86-64-O3的实测结果大致是朴素版本约 38ms表达式模板约 12ms。差距主要来自两次堆分配和额外的两轮遍历。如果你把表达式改成(a b) * 2.0 c表达式模板的优势会更加明显因为标量乘法节点几乎不增加任何成本而朴素实现会多出至少一个临时数组。还有一个关于优化的心得务必在开启优化的情况下测试比如至少-O2。在-O0下模板代码往往因为不内联而变得更慢于是你会得出“表达式模板没用”的错误结论。我见过不止一个同事在调试模式下评估性能然后直接把这个技术否掉。3.4 这一步还能怎么改进这套骨架最大的问题是没有做尺寸一致性检查。如果a和c的长度不一样Add::size()会取a的长度然后求值时越界访问c崩溃得很没品位。生产代码里应该在表达式节点里加一个断言比如assert(lhs.size() rhs.size())或者在最终赋值时用static_assert配合类型信息做编译期检查。内存管理上真实项目里建议改用std::vectordouble或std::spandouble来持有数据能少写很多析构和拷贝代码。还应该扩展更多运算节点比如减法、除法、内积、逐元素乘等。等你把常见的运算都补完了会发现代码模式高度统一每个节点就是“持有若干操作数引用 一个 size 一个 operator[]”这也是为什么表达式模板很容易用宏或代码生成工具批量产出。4. 进阶表达式模板在真实数值库中的形态4.1 混合标量与向量运算表达式模板最被低估的一点是它完全不破坏运算符优先级。Vec e a * 2.0 b;会被正常解析为(a * 2.0) b然后被翻译成AddScalarMulVec, Vec。标量2.0被折叠进节点内部不需要任何额外临时对象。当你把两种不同的节点组合在一起时CRTP 的静态分发依然能精确工作。比如(a b) * 2.0最后的节点类型是ScalarMulAddVec, Vec。这种嵌套在代码里看起来复杂但编译器处理得很好因为它只是类型层面的递归没有虚函数、没有运行时间接跳转。在我实际写过的点云滤波代码里经常出现out (cloud - mean) * weight offset这样的表达式。一个完整的表达式模板实现能把多个步骤融合成一次遍历这对几十万点的点云处理影响非常大。4.2 惰性求值和求值策略的博弈惰性求值是双刃剑我在这里吃过亏。假设你写了auto expr a b; a[0] 100.0; Vec d expr;由于expr持有的是a的引用最终的d会使用修改后的a[0]而不是表达式创建时的值。这在很多业务逻辑里是反直觉的你保存了一个表达式以为它定格了当时的计算结果实际上它只是个指向数据的计算计划。更麻烦的是对同一表达式求值多次的场景。Expr对象每次被转成Vec就会完整遍历一次如果你在一个循环里反复用它性能可能比朴素实现还差。这也是为什么 Eigen 内部对矩阵乘法这类高成本运算通常采用 eager evaluation求值缓存而对逐元素运算才放心使用 lazy evaluation。理解这个权衡很重要表达式模板不是“永远延迟计算更好”而是“在合适的时候延迟、在合适的时候立即算”。4.3 真实案例Eigen 的用法与权衡如果你去读 Eigen 的源码会发现整个库几乎是由表达式模板堆起来的。mat1 mat2 * mat3最终会生成一个极其复杂的表达式类型里面包含了矩阵乘法、加法、缓存策略、向量化分支等大量细节。你根本不会去手动写出这个类型名通常用auto或直接赋值给MatrixXd就好。Eigen 的实践给我的启发是表达式模板可以做成一个对外几乎透明的层。使用者写的代码和朴素版本一模一样性能却接近手写循环。它真正的成本在编译期——复杂表达式会让模板实例数量暴增编译时间从几秒涨到几十秒是常事。如果你维护一个构建时间敏感的中间层需要对表达式模板的使用范围做一些控制比如把公共的复杂表达式封装成具名函数降低每个编译单元的压力。4.4 编译期优化后发生了什么当编译器拿到AddAddVec, Vec, Vec的求值循环时它能看到完整的调用链expr[i]调用Add::operator[]里面又调用Add::operator[]和Vec::operator[]这些全部是内联的。于是循环体被展开成简单的a[i] b[i] c[i]编译器可以顺理成章地自动向量化生成 SIMD 指令大幅度提高计算密度。到了这一步你写的数学表达式和手写的高性能循环在汇编层面已经非常接近了。这也是为什么我会反复强调表达式模板是一门“把抽象成本降到零”的技术。它让代码保持可读性同时不牺牲底层控制能力。如果你需要极致的调优甚至可以基于表达式树结构在编译期做更多变换比如自动识别a * 1.0并把它优化掉或者把连续的加法链重组以减少指令依赖。5. 常见问题、坑位盘点与排查技巧5.1 悬垂引用表达式模板中最隐蔽的坑表达式节点保存的是引用那就意味着被引用的对象生命周期必须覆盖到求值完成之后。下面这样的代码是典型事故现场Vec make_sum(const Vec x, const Vec y) { return x y; // 返回表达式节点其中引用指向 x 和 y }如果调用Vec d make_sum(a, b);由于函数返回的是临时表达式节点而节点的引用指向a和b只要a、b在函数返回后还活着这次求值没问题。但如果你写成Vec d (Vec(100) a); // 左操作数是临时 Vec表达式求值发生在这一整行结束之前临时Vec还活着所以安全。真正的危险是你把表达式节点存起来auto expr a b;然后让a离开作用域再用expr。此时引用指向已经销毁的数据轻则结果错误重则直接段错误。注意表达式模板对象一定要按临时量使用。除非你极其清楚生命周期否则不要把它长期保存更不要跨函数传递。5.2 编译错误信息又长又乱怎么破表达式模板的编译错误是出了名的劝退。你少写一个const编译器可能报出几十行嵌套模板类型看上去像是天书。我的经验是先看错误信息的第一行它通常指明了哪个函数或哪个类型无法匹配再用static_assert做前置检查比如在Vec构造函数里加一句尺寸一致的断言让错误更早、更友好地被捕获。另一个实用技巧是想办法把模板类型打印出来。C 里可以用一个故意的编译失败强制编译器显示类型template typename T struct TypePrinter; TypePrinterdecltype(expr) tp; // 编译器会报出 expr 的完整类型C20 之后还可以用 concept 对表达式类型做约束错误信息会清晰很多。比如定义template typename T concept Expression requires(T t) { t.size(); t[0]; };然后让运算符只接受满足该 concept 的参数。5.3 性能不升反降怎么办我用表达式模板踩过的最大的坑是忘记开优化。默认的-O0下模板代码膨胀和内联失败会让性能比朴素实现更差。这不算技术问题而是评估方式问题。其次如果你保存表达式并多次求值惰性求值的优势会变成劣势这时候要么改成 eager 缓存要么就别用表达式模板。另外如果单个元素的计算本身很复杂比如包含函数调用、分支和查找表表达式融合带来的收益会被单次计算的成本稀释这时候不如老老实实写循环。定位性能问题我一般靠两样东西perf stat看指令数和缓存命中率perf record加火焰图看热点。表达式模板如果正常工作热点应该集中在求值循环本身而不是new和delete。如果你看到大量分配相关的调用说明表达式没有真正被融合多半是某个环节不小心返回了具体对象而不是表达式节点。5.4 实践中的速查表症状原因排查思路结果错误且随机悬垂引用检查所有表达式节点的引用生命周期编译报错几百行类型不匹配或缺少 const看第一行错误用 TypePrinter 打印类型性能反而更差未开优化、多次求值同一表达式确认 -O2 以上避免保存表达式复用崩溃在 operator[]尺寸不一致在节点里加 assert统一入口检查debug 下正常 release 崩依赖了未定义行为重点检查悬垂引用和越界访问说实话表达式模板是我在 C 里见过“收益和代价都极其鲜明”的技术。它能让数值代码的抽象层次提升一大截写的每一条运算都接近数学公式跑起来却和手写循环差不多快但代价是编译时间变长、错误信息变烂、生命周期必须小心翼翼。我最后分享一个经验不要一上来就在大型项目里全量引入表达式模板。先拿一个百行规模的向量类当试验田实现一次a b c亲手对比性能亲手体会模板类型展开的过程。等你能顺畅地读懂AddAddVec, Vec, Vec时再考虑把它用到真正的性能热点。这个节奏我在多个项目里验证过稳。