C++20 ranges的“策略内联”机制：从类型抹除到编译期优化

1. “策略内联编译器”这个叫法，说穿了是一套编译期约定

查 C++ 标准文档的人大概率会困惑：std::ranges 里根本没有一个叫 inline_compiler 的类，甚至连“策略编译器”这种名字都找不到。但很多老手聊起 ranges 库性能优势时，确实会用“等于带了一个策略内联编译器”这种说法。我琢磨了很久才反应过来，这不是某个组件，而是对 C++20 以来 ranges 设计范式的一种准确描述。

所谓“策略”，指的是你给算法或视图传进去的谓词（predicate）、投影（projection）、哨兵（sentinel）这些“行为参数”。传统 C 风格代码里，这些行为通常表现为函数指针：调用方提供一个地址，被调用方在运行期跳过去执行。而 ranges 的做法完全不同，它把行为表达成函数对象，通过模板参数传给视图和算法。这就等于每个行为参数都带着完整类型信息进入编译单元，编译器有机会在编译期把函数调用消解成内联指令，甚至直接做常量折叠——于是“策略”被“内联编译”成了一小段目标准确的机器码。

这套东西不是无中生有的优化，而是从模板元编程、表达式模板一路继承下来的“类型即协议”思想。C++11 之前我们写回调，最舒服的方式也就是函数指针或者虚函数。函数指针的调用在大多数情况下是间接调用，虚函数则是查虚表，两者都会把编译器挡在门外，它的优化策略根本伸不进去。lambda 表达式普及之后，函数对象成为主流的回调载体，但因为语法和 API 设计的问题，很多库仍然要求把 lambda 转成 std::function，或者强转为函数指针。ranges 库从根上避免了这个问题：所有行为参数都作为模板实参完整保存，不在运行期做任何类型抹除。于是传统意义上需要运行期多态解决的问题，被挪到了编译期。

标题里的“编译器”三个字也容易让人误解。ranges 并没有发明一个新的编译器，它靠的还是 GCC、Clang 或 MSVC 的优化器。它的贡献在于提供了一套结构，让用户的策略对象总是以“最容易内联的形态”出现在算法实现面前。换句话说，ranges 负责把策略送到优化器嘴边，优化器自然也就愿意张嘴。从这个角度看，“策略内联编译器”更像一个工程实践总结，它由三块拼图组成：concept 约束让不合适的调用在编译期就被拒绝；定制点对象（CPO）让容器和迭代器的底层操作全部走可见代码路径；视图适配器则通过嵌套模板类型把多个策略组合成一棵可以直接展开的表达式树。

这篇文章我会把这三块拼图分别拆开，再从实测代码的角度，看一段常见的 view 链在优化后的真实行为。最后会聊几个我踩过的坑，都是会把 ranges 这套“策略内联”机制彻底废掉的写法。

2. ranges 的三个底层机制，是怎么把策略推向编译期的

2.1 CPO：包装 ADL 调用的透明壳

ranges 库中最容易被忽略、却最影响内联效果的是定制点对象，常见的 ranges::begin、ranges::end、ranges::size 都是这个形态。

CPO 的概念有点绕：它是一个全局函数对象，但在内部通过概念检查决定“该走哪条路”。比如你先对原生数组调用 ranges::begin(arr)，它应该返回数组头指针；对标准容器调用，它应该调用容器的成员函数 begin()；对某些自定义类，它又可能走 ADL 找到的自由函数 begin。传统实现这种分派需要虚函数或者运行时判断，但 CPO 把每个分支都写成了概念约束下的普通函数模板，编译期就已经确定走哪个分支。

为什么这对“策略内联”很重要？因为算法最终要获取范围的首尾位置，如果这一步发生虚调用，或者通过 std::function 间接跳转，后面一切优化都无从谈起。CPO 从设计上保证了底层迭代器获取操作是“透明”的：优化器看到的是一个个内联候选函数，参数类型在编译期完全已知，层层包裹会被逐层扒开。实际生成的代码里，ranges::begin(v) 往往只剩一个返回容器内部指针或者迭代器的简单操作，没有封装痕迹。

在上帝视角看，CPO 很像给 ADL 机制加了一扇正式的门。过去我们写泛型代码用 using std::begin; begin(c); 来兼容数组和标准容器，CPO 把这段经验文本化、规范化了。而门里面每一条路都是编译期分派，天然不阻碍函数内联和死代码消除。

2.2 concept 约束：编译期的“策略契约”

策略要有意义，得先被放进合适的上下文。比如 filter_view 要求你传入的谓词对迭代器解引用结果返回可转换到 bool 的值；transform_view 要求传入函数可调用且返回值类型不违反 view 的约束条件。这些检查在 concept 出现之前用的是 SFINAE 和一堆让人头皮发麻的 enable_if，而 ranges 库直接把这些表达成了概念。

概念不光是提高错误信息可读性，它也是“编译期编译器”的输入条件。以 std::predicate<F, Args...> 为例，编译器需要在编译期确认 F 可以被 Args... 调用，并且返回值可以转换成 bool。这个检查一旦通过，后续模板的实例化路径就会被记录下来。换句话说，编译器在编译期间就已经把“这个谓词在此处合法”当成了事实。内联优化的前提之一是代码路径可以被唯一确定，concept 收紧了类型范围，让代码路径变得更加具体。

另一个容易忽略的细节是，概念约束可以参与重载决议。同一个策略对象可能同时适用于 filter 和 find_if，但因为约束和迭代器类别不同，编译期会选出一条行为完全确定的路径。这样设计出来的泛型代码，风格上更像“一张在编译期运行的类型级决策表”，而不是经典动态分发。

2.3 为什么统一用函数对象，而不是函数指针或 function

ranges 内部从算法到视图，几乎所有的“策略参数”都以模板参数形式接收函数对象。这样做有一个直接的性能来源：空 lambda 对象大小是 0 字节（EBO 优化后），把它存进视图类里不会增加额外体积；如果有非空捕获，类型也能精确描述对象占多大、怎么拷贝。

函数指针就不具备这些优势。函数指针本身是运行期数值，谁也无法保证它指向的函数定义可见。编译器能拿到一个地址，但看不到函数体，内联自然无从谈起。std::function 就更差一截，它要在类型擦除层多次跳转，还要处理堆分配和小对象优化。当策略对象是 std::function 的时候，ranges 类型系统里看到的只是一个“不透明的调用器”，优化器无从下手。

用函数对象还有一个隐性好处：调用约定可以高度定制。lambda 的 operator() 可以直接内联，可以标记 noexcept，甚至可以 consteval。函数指针不可能携带这些编译期属性。所以如果一个 filter 视图里的谓词写成一个空类型 lambda，它在优化后的代码里经常彻底消失，只留下谓词体中的整数运算和判断。

3. 一段 view 链在优化器手里会经历什么：从管道符到单循环

3.1 先看一段典型的惰性组合代码

理论讲多了容易飘，先用一段可以编译运行的代码看看实际效果。

cpp复制#include <algorithm>
#include <iostream>
#include <ranges>
#include <vector>

int main() {
    constexpr auto div3 = [](int n) noexcept { return n % 3 == 0; };
    constexpr auto sq = [](int n) noexcept { return n * n; };

    int sum = 0;
    std::vector<int> v(1'000'000);
    std::iota(v.begin(), v.end(), 1);

    for (int x : v
               | std::views::filter(div3)
               | std::views::transform(sq)
               | std::views::take(3)) {
        sum += x;
    }

    std::cout << sum << '\n';
}

这个程序在支持 C++20 ranges 的编译器上能正确输出 126，因为前三的偶三倍数分别是 3、6、9，平方和就是 9 + 36 + 81 = 126。

这段代码最容易让新手误解的地方是：filter(div3) 真的会把整个 100 万大小的 vector 先筛一遍吗？不会。std::views::filter | std::views::transform | std::views::take 组合出来的是一个惰性视图。每次 for 循环要下一个元素时，视图链才会往前推动迭代器。取到第三个平方值后，take 视图直接让迭代器到 end，整个循环停下来。vector 只有前几个元素会被访问。

3.2 编译器视角：函数调用边界消失

view 链的特点在源码层面是“复合对象”，每个 | 都构造了一个嵌套模板类型。这段链条实际结构大概是：take_view<transform_view<filter_view<vector<int>::iterator, vector<int>::iterator>, lambda_sq>, lambda_div3>>。每个视图类都保存了底层迭代器或范围，以及策略对象。看源码会觉得好多层，但优化器不在乎这种嵌套，它拥有所有类型的完整定义，能一层层递归展开 operator++、operator* 和 strategy。

在 O2 编译下，展开后的循环逻辑大致等于手写这样一段：

cpp复制for (auto it = v.begin(), end = v.end(); it != end; ++it) {
    if (*it % 3 == 0) {
        int t = (*it) * (*it);
        sum += t;
        ++fetched;
        if (fetched == 3)
            break;
    }
}

谓词的 lambda 类型在编译期被完整翻译成了函数体中的 % 3 判断和乘法指令。访问 view 迭代器时，std::vector::iterator 本身是指针别名，所以解引用就是普通的内存访问。最终生成的机器码里没有堆分配、没有间接跳转、没有额外的函数调用来来回回。

我在 Compiler Explorer 里看这段代码的汇编时发现，靠近循环内部的调用基本都被内联进去了，核心代码就是比较、取模、乘法、累加和跳转。如果进一步把 div3 改成“取后四位等于 0”这种复杂条件，仍能看到 lambda 的条件分支与整个循环融合在一起。这说明 ranges 的“策略内联”不是某一种特殊指令组合，而是把策略函数体当作普通代码直接嵌进循环控制流。

3.3 惰性的本质：迭代器把所有策略压进“同一趟 walk”

很多初学 ranges 的人总觉得惰性求值只是“不急着算”。其实惰性求值对编译期的影响更大：因为它把多个策略藏在了迭代器的自增和比较操作中，而不是先完整跑完一个链式集合再跑第二个集合。这样设计出来的结构天然容易让编译器做所谓的“循环融合”（loop fusion）。

举个反例，如果实现一段急切求值版本的 filter-then-transform，那么代码必然长这样：

cpp复制std::vector<int> tmp1;
std::copy_if(v.begin(), v.end(), std::back_inserter(tmp1), div3);
std::vector<int> tmp2;
std::transform(tmp1.begin(), tmp1.end(), std::back_inserter(tmp2), sq);

这里有两个临时数组、两次完整遍历。编译器就算再聪明，也很难跨语句消除这两个数组，因为中间结果可能被观察到、也可能因为别名而不敢优化。ranges 通过迭代器一步步逐个推进把两次遍历压成一次，本质上从一开始就消灭了临时存储。

不过也要说句公道话，view 链并不保证编译器一定能融合出比手写代码更好的结果。iota_view 这类无所有权视图配合简单 transform，融合效果非常好。但如果你的策略链太长、迭代器分类比较复杂，编译器也可能生成比手工循环略差一点的代码。好在绝大多数业务代码的瓶颈根本不在这一层，能够省掉中间数组和分配已经是巨大的收益。

4. 自己写 range 适配器时，怎么保证“策略”能被内联到底

4.1 适配器的对象布局：策略要作为可推导模板类型来存

这里有一个常见误区：很多人觉得 ranges 性能好纯粹是因为编译器“给力”，自己写一个仿 ranges 的容器却仍然把策略抽象成基类接口，然后塞智能指针。这是最典型的把内联机会亲手杀掉的做法。

写一个自定义 view 适配器，如果想要继承 ranges 的“策略内联”特性，首先要在模板参数中接收函数对象类型并作为值成员保存。下面是一个结构示意，能说明问题：

cpp复制template <std::ranges::input_range R,
          std::predicate<std::ranges::range_reference_t<R>> Pred>
    requires std::ranges::view<R>
class my_filter_view : public std::ranges::view_interface<my_filter_view<R, Pred>> {
private:
    R base_;
    Pred pred_;

public:
    my_filter_view() = default;
    my_filter_view(R base, Pred pred)
        : base_(std::move(base)), pred_(std::move(pred)) {}

    // begin / end 的实现需要按 filter_view 的迭代器语义进行，
    // 这里省略完整细节，重点是 pred_ 一定要作为值成员类型保留。
};

这里 Pred 是模板类型参数，不是基类指针，也不是 std::function。只要满足 view 概念，用户传入的 lambda 闭包类型就能被完整保留在 my_filter_view 对象里。优化器知道这个对象成员的准确类型和大小，自然也就看得到 pred_ 的 operator() 实现。

4.2 迭代器内部如何引用策略

更隐蔽的坑在迭代器实现里。很多人会把迭代器写成持有指向父视图的指针或者引用，然后通过父视图去访问策略对象。这在 ranges 设计里很常见，标准库的 filter_view::iterator 就是存了指向父视图的指针。

但如果你自己写迭代器时用 std::shared_ptr 来共享策略对象，那策略对象的类型虽然还是模板参数，运行逻辑却变成了访问堆上对象。每次 operator* 或者 operator++ 都多一次指针间接访问，读一遍还是小事，堆分配和 shared_ptr 引用计数开销才是大头。现代编译器的优化器对指针别名的分析有很强能力，但能让它省心的地方就不要留给它做启发式推理。

正确做法是尽量让适配器对象总大小保持极小，并且不含有堆资源。如果策略对象有大量捕获，尽量把捕获设计成值语义或紧凑引用语义。例如捕获一个 std::string_view 比捕获一个 std::string 更友好，前者不会在迭代过程中触发深拷贝。

4.3 让 operator() 以透明方式暴露给优化器

除了存储形式，调用点还需要注意三个细节：不要把策略对象塞进虚函数边界、不要用函数指针存储、不要在本可以 noexcept 的地方省略 noexcept。

虚函数问题很好理解，一旦策略对象作为基类指针被调用，优化器就无法确定实际的 operator() 是哪一个；函数指针同理，它指向的函数体可能看不到；而 noexcept 虽然不直接影响内联决定，但它能去掉大量异常处理路径，能让优化器从容地清理无用控制流。

这里还值得提一下 C++ 的概念约束：如果你的自定义适配器构造函数没有约束 Pred 必须满足可调用，而只是用裸模板接收，那么在传入不可调用对象时，错误会延迟到迭代器 operator* 实例化阶段才爆发。那些编译错误往往有几百行，新手直接看哭。反过来，用 std::predicate 约束以后，编译器能更早地把人的意图与策略类型匹配起来，错误信息也会集中在构造函数被调用的那行，而不是迭代器深处。这同样是“编译器”机制的一部分：它在策略进入适配器之前，就完成了一批类型检查。

4.4 一段能看出效果的简易投影视图

下面这个例子比完整自定义 filter 简单，但能实际体现策略内联的收益。假设我想写一个“把元素通过投影函数转换后再遍历”的视图，其实标准库里就是 std::views::transform。如果为了教学自己造一个，可以这样处理：

cpp复制class my_transform_view {
    // 其实标准库的实现已经足够完善
    // 自己造只是为了验证内联机制
};

标准库的 transform_view 会存两个成员：底层范围 V base_ 和函数对象 F fun_。迭代器每次 operator* 的时候执行 fun_(*it)。而 fun_ 的类型作为模板参数暴露，调用函数在头文件内可见。最终一个 my_transform_view 实例的实际运行，会比你想象的更“扁平”。

这也解释了为什么我在项目里几乎从不自己写基础视图适配器：标准库把存储方式、迭代器分类、哨兵处理都做完了，自己写反而很容易写出比标准库更慢的版本。但如果你想给团队提供业务专用适配器，比如“过滤无效日志后把日志级别映射为字符串”，那就可以顺着标准库这套“策略即模板成员”的架构，封装出一个类型安全的适配器。封装好后，传入的解析器和过滤器都能被编译器当作普通内联函数处理。

5. 实践里最常见的 3 个内联杀手，我全踩过

5.1 std::function 包裹谓词：一次隐蔽的虚调用

最开始接触 ranges 的时候，我在一个日志过滤模块中写了类似这样的代码：

cpp复制std::function<bool(const LogEntry&)> filter = [](const LogEntry& e) {
    return e.level >= Level::Warning && e.message.find("timeout") != std::string::npos;
};

auto view = logs | std::views::filter(filter);

代码编译通过，运行也正常。但性能测试的时候发现这段过滤比普通 for 循环慢了接近 30%。一时间我没想通，明明 ranges 设计那么好，为什么这里会慢。

原因在 std::function 的类型擦除。filter 变量的类型不再包含 lambda 信息，它内部通过小对象优化存储 lambda，但在调用时会走一个指向内部管理的函数指针或虚函数表通道。std::views::filter 拿到的 Pred 类型是 std::function<bool(const LogEntry&)>，优化器看不到 std::function::operator() 到底调谁，因为它内部是一个运行期可变目标。这样谓词体被完全隔离在优化视野之外。

解决方式非常简单：把 std::function 类型去掉，直接让 lambda 进入视图链。

cpp复制auto view = logs
    | std::views::filter([](const LogEntry& e) {
        return e.level >= Level::Warning
            && e.message.find("timeout") != std::string::npos;
      });

改完之后同一段逻辑几乎和手写循环持平，视图链的迭代器一步步前进时所有判定都内联进了 operator++ 与 operator* 路径。这件事之后我再也不在产品迭代路径里用 std::function 作为 ranges 策略的包装层。

5.2 把策略对象传给独立编译单元的接口

第二种情况更隐蔽。某个组件内部实现了 ranges 的过滤逻辑，为了做单元测试，对外暴露一个接口：

cpp复制// 接口声明
process_logs(const std::vector<LogEntry>& logs,
             const std::function<bool(const LogEntry&)>& filter);

然后组件实现内部再调用 std::views::filter(filter)。接口处用 std::function 相当于在模块边界上做了一次类型擦除，优化器在这一侧彻底看不到调用方的 lambda 是什么。更糟糕的是，如果调用方的谓词是想捕获临时状态，那么 std::function 还会引入一次堆分配或者拷贝。这个堆分配可能发生在每次调用接口之前，对高频小日志批次影响尤其明显。

适合 ranges 的接口设计不要使用 std::function，应当把谓词做成模板参数。比如：

cpp复制template <typename Pred>
void process_logs(const std::vector<LogEntry>& logs, Pred pred) {
    for (const auto& e : logs | std::views::filter(std::move(pred))) {
        // ...
    }
}

模板接口能保证在实例化点看到谓词函数体。编译器会把过滤逻辑与组件内部其他算法直接联合优化。当然模板接口可能让头文件暴露更多实现细节，但这种性能敏感的处理路径通常本来就该留在头文件或同一个翻译单元里。

如果团队铁了心要用 ABI 稳定的动态库接口，那就得接受跨模块的优化损失，然后退而求其次把过滤逻辑挪到动态库内部，而不是把策略对象传进去。这也是我后来重构时的一个原则：策略不要越过模块边界，模块边界上只放数据。

5.3 视图链中混入会让迭代器类型退化的操作

ranges 里有一些视图适配器虽然方便，但会引入额外的间接层。最典型的是把整个 view 转成 std::vector，或者调用 views::common 强制把 end 哨兵转回原迭代器类型。后一种操作有时候是必要兼容，但如果你想利用 ranges “不同结束类型的信息”，就要慎用。

标准库的迭代器包含了更多的结束信息，比如无限 iota 视图、filter_view 的哨兵等。这些信息在编译期可能是不同的类型。当 views::common 强行让 begin 与 end 返回相同类型时，某些优化信息就被抹掉了。倒不会直接导致策略无法内联，但可能让循环边界的比较变得更保守，错过一些循环优化机会。

我遇到的具体场景是把 ranges 管道结果传给一个只接受 begin/end 同类型的旧接口。当时贪图方便直接 std::views::common 包了一下。后来性能分析发现循环内多了一个不必要的边界检查。改为重构旧接口接受 ranges::begin / ranges::end 后，边界信息重新完整，额外的检查就消失了。

还有一类问题来自迭代器自身：如果你在 transform 里转换出的返回值需要拷贝到新的临时字符串，恰巧类型又是 std::string，那任何编译器都无法消除这个对象的构造析构开销。策略虽然内联了，但“策略产生了一个大临时对象”这件事，内联是无能为力的。要优化应该从数据形态下手，比如改成 string_view 或使用更小的返回载体，而不是指望 ranges 帮你变出魔法。

6. 经验谈：写 ranges 策略前先想想“编译器能看见什么”

在我接触 ranges 的这些年里，最大的体会是：不要把它当运行期黑盒去“调用”，而要把它当成一套编译期类型组装工具去“设计”。每次写一个 predicate、projection 或者自定义 view 适配器之前，我都先问自己一个问题：编译器在这个调用点，能不能看到策略对象的完整实现？

如果答案是能，那么大概率会收获一段接近手写循环的高效代码，同时代码表达力比手写循环高很多。如果答案是不能，那不管编译器优化多努力，最终都会在某个地方发生间接调用、类型擦除或边界保守，性能也会随之打折扣。这一点在写库接口时尤为重要，头文件里保存策略并要求实例化点在调用处，是我们团队内部默认风格。

另外一个小建议：调试这套机制时，与其全凭“感觉”或看反汇编，不如直接在 https://godbolt.org 上写个小例子，开启 -O2 还能顺手看 -fopt-info 之类的优化日志。不直观的层数一多，汇编里有没有 call 指令、有没有 std::function 的堆分配痕迹，其实一眼就能看出来。装配出可预测的高性能代码，这件事本身也很有乐趣。