C++ ranges怎么过滤并转换容器数据-C++-PHP中文网

最直接标准做法是用 std::views::filter 和 std::views::transform 构建惰性视图，避免中间容器分配；lambda 不能捕获，需改用函数对象或传参；链式顺序必须为 filter 在前、transform 在后；转 vector 推荐 C++23 的 std::ranges::to()，C++20 需先 reserve 再 copy；filter_view 不可写，不拥有数据，仅跳过元素。

c++ ranges怎么过滤并转换容器数据

用 `std::ranges::filter_view` + `std::ranges::transform_view` 链式组合最直接

标准做法不是“先过滤再转换成新容器”，而是构建一个惰性视图（view），只在需要时计算。这样避免中间临时 std::vector 分配，也符合 ranges 的设计哲学。

常见错误是试图用 std::ranges::copy 强制立刻求值却忘了目标容器要预先分配空间，或者误以为 transform_view 能直接接受 lambda 捕获——它要求可默认构造，捕获 lambda 不满足这点。

必须用 std::views::filter 和 std::views::transform（C++20 推荐写法，比裸 view 类型更简洁）
lambda 不能带捕获；如需外部变量，改用函数对象或把变量传入 lambda 参数（比如通过 std::bind 或闭包外提）
链式顺序很重要：vec | std::views::filter(...) | std::views::transform(...) 是合法的，反过来则类型不匹配
如果最终真要转成 std::vector，得显式调用 std::ranges::to<:vector>()（C++23）或手动 std::ranges::copy 到已预留容量的容器

想立刻得到 `std::vector`？用 `std::ranges::to`（C++23）或手动 `std::ranges::copy`

std::ranges::to 是最干净的方案，但仅限 C++23。C++20 用户得自己处理目标容器生命周期和容量——否则 push_back 可能引发多次重分配。

典型错误：对空 std::vector 直接 std::ranges::copy(view, std::back_inserter(vec))，性能差；或用 vec.begin() 却没保证 size 足够，导致越界写。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

C++23：auto result = view | std::ranges::to<:vector>();
C++20：std::vector result; result.reserve(std::ranges::distance(view)); std::ranges::copy(view, std::back_inserter(result));
注意 std::ranges::distance 对某些 view（如 istream_view）是 O(n)，别滥用在未知长度输入上

`std::views::filter` 的谓词为什么不能修改元素？

因为 filter_view 只读遍历原始 range，它内部存储的是迭代器对，不拥有数据，也不允许通过它间接修改原容器。如果你看到“无法赋值给 filter_view 的元素”，说明误用了 auto& 绑定到 view 的 operator[] 返回值——那其实是 const 引用或 proxy 类型。

要修改原容器中符合条件的元素，得先拿到原始迭代器（比如用 std::ranges::find_if 或循环原始容器 + 手动判断）
filter_view 的唯一职责是“跳过”某些元素，它不提供写入接口
试图对 filter_view::iterator 解引用后赋值，编译会失败，错误信息类似 assignment of read-only location

性能关键点：避免重复计算和意外拷贝

view 链本身几乎零开销，但一旦嵌套复杂 lambda 或频繁调用 std::ranges::distance，就可能拖慢。更隐蔽的问题是：某些 view（如 transform_view）的迭代器解引用会每次调用 lambda——如果 lambda 有副作用或耗时，就会被反复触发。

不要在 transform lambda 里做 IO、锁、或大对象拷贝；如有必要，提前计算好并捕获（但注意前面说的捕获限制）
避免对同一个 view 多次调用 std::ranges::size 或 std::ranges::distance，尤其当底层是 forward_range 甚至 input_range 时
如果原始数据是 std::vector 且确定要全量处理，有时传统 for 循环反而更清晰、更容易被编译器优化

真正容易被忽略的是 view 的 lifetime：所有 view 都引用原始 range，一旦原始容器析构，view 迭代就变成悬垂。别把 view 存成类成员，除非你 100% 控制了底层容器的生命周期。