c++ c++26 aot aot aot c++标准库的std::execution如何使用-C++-PHP中文网

c++oding="utf-8" ?>

std::execution 在 c++26 中并不存在，它仅是 c++17 引入的并行算法执行策略（如 seq、par、par_unseq），不提供执行器或调度器抽象，所有所谓“c++26 新特性”均属误传。

c++ c++26 aot aot aot c++标准库的std::execution如何使用

std::execution 在 C++26 中还不存在

它根本没进标准。C++23 是当前最新正式标准，C++26 尚在草案阶段（ISO/IEC PDTS 23979），而 std::execution 这个命名空间——连同 std::execution::par、std::execution::seq 等执行策略——早在 C++17 就已存在，但仅作为 std::for_each、std::sort 等并行算法的参数类型，不提供独立调度或执行器抽象。

常见错误现象：std::execution::task_block 或 std::execution::executor 编译失败；搜索“C++26 execution”后误以为新特性已落地，结果发现头文件不识别、文档链接 404。

C++17 引入的是 std::execution::sequenced_policy 等策略类型，不是运行时执行器
C++23 没新增执行模型，只微调了并行算法约束和异常传播行为
PDTS 23979（C++26 草案）里确实提到了 “execution primitives”，但全是提案编号（如 P2300R7 的 std::execution 重构），未合并进标准正文
所有主流编译器（GCC 14、Clang 18、MSVC 19.39）均不支持所谓“C++26 std::execution”新接口

现在能用的 std::execution::xx 都是 C++17 并行策略

它们只是枚举式标签，告诉算法“你允许怎么并发”，不启动线程、不管理队列、不处理依赖。真正干活的是标准库实现（比如 libstdc++ 用 pthread / TBB，libc++ 用 Intel TBB 或自研线程池）。

使用场景：加速已知可并行的 CPU 密集型操作，比如大数组排序、向量归约、图像像素遍历。

std::execution::seq：强制顺序执行（单线程，无开销）
std::execution::par：允许任意并发（可能用多线程，也可能退化为 seq）
std::execution::par_unseq：允许并发 + 向量化（SIMD，对数据布局敏感）
必须显式传给算法，如 std::sort(std::execution::par, first, last, comp)；不传就是顺序版

性能影响：用 par 不一定更快——小容器、廉价比较函数、缓存不友好访问模式下，线程启动/同步开销反而拖慢；建议先测 seq 基线，再比 par。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

想写 AOT 友好的并行代码？别碰 std::execution 策略

AOT（Ahead-of-Time）编译环境（如嵌入式、iOS、某些游戏引擎构建链）通常禁用动态线程创建、限制 STL 的并发实现。而 std::execution::par 的行为高度依赖运行时线程池，libstdc++ 默认用 std::thread，libc++ 依赖外部 TBB —— 这些在 AOT 场景下往往不可控或被裁剪。

容易踩的坑：

静态链接时漏掉 TBB 库 → 运行时报 undefined symbol: _ZNSt3__119__tbb_backend_impl14__execute_taskEPv
iOS 构建开启 -D_GLIBCXX_PARALLEL → 直接编译失败（Apple Clang 不支持）
裸机或 freestanding 环境包含 <execution></execution> → 头文件存在但策略对象定义为空，链接时报错
用 par_unseq 但数据未按 32 字节对齐 → SIMD 指令触发 SIGBUS

替代做法：显式用 std::thread + std::vector<:thread></:thread> 分块，或选轻量级并行库（如 OpenMP 的 #pragma omp parallel for，AOT 兼容性好得多）。

std::execution 相关提案（P2300）和现实差距很大

P2300（“std::execution” 重构）想把执行器、发送器、接收器做成一等公民，类似 Rust 的 Executor 或 Swift 的 Task，但它仍处于 TS（Technical Specification）讨论阶段，连 C++26 的 feature testing macro（__cpp_lib_execution）都未启用。

现状：

没有 std::execution::executor 类型
没有 std::execution::schedule() 函数
没有 sender/receiver 概念进入标准库头文件
所有实验性实现（如 LLVM 的 libcxx 的 experimental/executors）都带 experimental:: 前缀，且 ABI 不稳定

如果你看到博客写“C++26 使用 std::execution::schedule() 启动异步任务”，那要么是混淆了提案编号，要么在跑非标准分支。真要跨平台 AOT + 异步，目前更靠谱的是自己封装 std::jthread 或用 Boost.Asio 的 thread_pool。