indirect_array：C++里那个被遗忘的“索引遥控器”

你有没有试过，想从一个数组里挑几个特定位置的元素做批量运算，但又不想写一长串下标？比如把 arr[2], arr[5], arr[0], arr[7] 这四个数同时乘以 2，再加到另一个数组对应位置上。手写循环？可以，但啰嗦；用 std::valarray 配合 std::gslice？太重，还绕。这时候，indirect_array 就像抽屉深处突然摸到的一把老式万能钥匙——不常亮出来，但真用上时，咔哒一声，刚好对上锁芯。

indirect_array 是 <valarray> 头文件里一个极其低调的类模板，它本身不持有数据，也不管理内存，只负责“转译”一组整数索引，把它们变成对某个 valarray 的间接访问通道。它不是容器，不是视图，更不是现代 C++ 的 span 或 mdspan；它是 valarray 生态里一个带点复古气质的“协议层”——专为数值计算中高频、规则的索引跳转而生。

它的诞生背景很实在：上世纪 90 年代，C++ 标准委员会想给科学计算提供轻量级、可优化的数值数组支持。valarray 被设计成可被编译器深度向量化（比如自动展开为 SIMD 指令），而 indirect_array 就是让这种优化能延伸到“非连续索引访问”场景的关键一环。它不追求通用性，只解决一类问题：给定一个索引序列，对目标数组执行统一的、可向量化的操作。

怎么用？先看最简例子：

#include <valarray>
#include <iostream>

int main() {
    std::valarray<int> data = {10, 20, 30, 40, 50, 60, 70, 80};
    std::valarray<size_t> indices = {2, 5, 0, 7}; // 想操作第2、5、0、7号元素

    // 关键一步：通过 valarray::operator[] 返回 indirect_array
    auto subset = data[indices]; // 注意：这不是拷贝，是视图！

    // 对这四个位置的值统一加100
    subset += 100;

    // 此时 data 变为：{110, 20, 130, 40, 50, 160, 70, 180}
    for (int x : data) std::cout << x << ' ';
}

这里没有 for 循环，没有指针算术，甚至没显式解引用。data[indices] 返回的 indirect_array<int> 对象，把后续所有算术操作（+=, *=, sin() 等）自动“重定向”回 data 的指定位置。它的本质是一组“活链接”，而非数据副本。

但注意一个易踩的坑：indirect_array 不能脱离原 valarray 独立存在。一旦 data 被移动、析构或重新赋值，再用 subset 就是悬空访问。它不像 std::span 有生命周期管理机制，这点必须手动盯紧——就像借了别人的遥控器，得记得还，否则对方关机后你还按着“开机键”。

那它和 std::vector 配合 for_each + lambda 有什么区别？实测过就知道：在开启 -O3 -march=native 的编译器下，indirect_array 的批量赋值/运算，往往生成更紧凑的汇编指令。原因在于，valarray 的设计允许编译器在编译期就推断出操作的“可并行性”和“无副作用性”，而 indirect_array 把这种语义显式暴露了出来。它不是更快的语法糖，而是向编译器递了一张明确的优化通行证。

不过，现实很骨感：indirect_array 不支持迭代器，不能用范围 for，也不能传给 std::algorithm。你想排序这四个数？不行。你想找最大值？得先 .copy() 到临时 valarray 再调 max_val()。它的能力边界非常清晰：只做“映射+统一运算”，不做“遍历+任意逻辑”。 这不是缺陷，是设计取舍——就像螺丝刀不负责拧钉子，锤子不负责划线。

真正适合它的场景，其实是那些“模式固定、批量重复”的数值任务。比如图像处理中，对某几行像素做伽马校正；物理模拟里，对特定粒子编号的坐标数组施加外力；甚至金融建模中，对一组选定合约的收益率做统一波动率调整。只要索引序列能预先算好（哪怕是从文件读入），indirect_array 就能干净利落地完成后续数学操作。

顺带提一句冷知识：indirect_array 支持嵌套索引。比如 data[indices1][indices2] 是合法的（前提是 indices1 返回的是 valarray 类型），这在实现稀疏矩阵的块操作时曾有奇效——当然，现在更多人用 Eigen 或 xtensor，但理解这种设计思路，对读老代码或做底层优化仍有价值。

最后说句实在话：今天写新项目，大概率不会主动选 indirect_array。std::span + std::ranges::transform 更现代、更安全、生态更好。但它存在的意义，不只是“能用”，更是提醒我们：C++ 的数值抽象，从来不止于容器与算法的组合；有时候，一个极简的、契约明确的中间层，反而比大而全的框架更能逼近硬件效率。

下次当你又在写 for (auto i : {2,5,0,7}) arr[i] *= scale; 的时候，不妨停半秒——那个被标准尘封的 indirect_array，其实一直在等一个懂它使用场景的人。