c++的co_await和co_yield在协程中分别扮演什么角色? (异步编程)

co_await用于挂起协程等待异步操作完成,触发await_ready/await_suspend/await_resume协议;co_yield用于generator中产出值并挂起,是promise.yield_value的语法糖。

co_await 用于挂起并等待异步操作完成

co_await 的核心作用是把当前协程暂停,交出控制权,等某个 awaitable 对象(比如 std::future、自定义的 awaiter)就绪后再恢复执行。它不是简单“等”,而是触发一整套挂起/恢复协议:调用 await_ready 判断是否可立即返回,否则调用 await_suspend 注册恢复逻辑,最后通过 await_resume 取回结果。

常见错误现象包括:

  • 对非 awaitable 类型(如普通 int)使用 co_await,编译报错 no matching function for call to 'operator co_await'
  • 忘记在 await_suspend 中正确传递 coroutine_handle,导致协程永远不恢复
  • await_resume 中抛异常但没处理,引发未捕获异常终止

典型使用场景是等待 I/O 或定时器:

task fetch_data() {
    auto res = co_await http_get("https://api.example.com/data"); // 挂起,等网络响应
    co_return res.status_code;
}

co_yield 用于向协程生成器输出值并挂起

co_yield 只在 generator 这类协程类型中合法,它的本质是 co_await promise.yield_value(value) 的语法糖。每次执行 co_yield x,协程就把 x 交给调用方(比如 for-range 循环),然后挂起,等待下一次迭代时被唤醒。

关键点:

  • 不能在返回类型为 taskvoid 的协程里用 co_yield,否则编译失败
  • co_yield 不负责调度,也不等外部事件;它只是“产出 + 挂起”,恢复时机由调用方控制(如 ++it
  • 如果 yield_value 返回 void,协程挂起后无法被唤醒,容易卡死

示例:

generator fib(int n) {
    int a = 0, b = 1;
    for (int i = 0; i < n; ++i) {
 

co_yield a; int next = a + b; a = b; b = next; } }

co_await 和 co_yield 的底层行为差异

二者都依赖协程 promise 类型的成员函数,但触发路径不同:

  • co_await expr → 调用 expr.operator co_await() → 最终调用 promise.await_transform / await_ready
  • co_yield val → 展开为 co_await promise.yield_value(val) → 所以必须确保 promise.yield_value 返回一个 awaitable

性能上:co_await 可能引入调度延迟(如线程切换),而 co_yield 通常只是栈保存+跳转,开销更低;但两者都避免了传统回调嵌套,提升可读性。

兼容性注意:co_yield 在 C++20 中要求编译器支持 generator(如 MSVC 19.3x+、Clang 16+),GCC 13 才开始实验性支持;co_await 支持稍早,但 awaitable 实现仍需谨慎适配 ABI。

容易混淆的边界情况

最常被忽略的是协程类型与关键字的绑定关系:

  • task 协程却误用 co_yield:编译器报错 'co_yield' cannot be used in a coroutine that does not support yielding
  • generator 却只用 co_await 不用 co_yield:协程变成单次执行,失去“迭代器”语义
  • co_await 表达式里调用一个返回 generator 的函数,却不遍历它:只是构造了一个未启动的 generator 对象,不会触发任何协程逻辑

真正要记住的不是语法,而是每个关键字背后绑定的 promise 接口契约——一旦 promise 缺少对应成员,编译就断在那儿,没有运行时妥协余地。