c++的co_await和co_yield关键字如何使用? (协程核心)

C++20协程函数需满足三条件:返回类型含promise_type嵌套类型;该类型提供get_return_object等四个必需成员函数;函数体含co_await/co_yield/co_return之一。

这两个关键字本身不直接“使用”,它们只在 co_awaitco_yield 表达式中出现,且仅允许出现在 协程函数(即返回类型满足协程要求、含 co_await/co_yield/co_return 的函数)内部。强行在普通函数里写会编译失败。

怎么让一个函数变成协程函数?

不是加个 co_await 就行——C++20 要求函数满足三个条件:

  • 返回类型声明了 promise_type 嵌套类型(如 std::futuretask 等自定义类型)
  • promise_type 至少提供 get_return_object()initial_suspend()final_suspend()unhandled_exception() 四个成员
  • 函数体中至少出现一次 co_awaitco_yieldco_return

标准库没提供开箱即用的协程返回类型(std::generator 是 C++23 才加入的),所以你大概率得自己写 task 或用第三方库(如 libcorocppcoro)。否则连编译都过不去。

co_await 的实际行为取决于 awaiter

co_await expr 时,编译器会尝试从 expr 构造一个 awaiter 对象(通过 expr.operator co_await()operator co_await(expr)),然后调用它的三个关键方法:

  • await_ready():返回 bool,若为 true,则不挂起,直接执行后续逻辑
  • await_suspend(coroutine_handle h):决定是否挂起;若返回 void,表示挂起并移交控制权;若返回 booltrue

    表示挂起,false 表示继续执行;若返回另一个 coroutine_handle,则直接跳转到那个协程
  • await_resume():挂起恢复后调用,其返回值成为 co_await expr 整体表达式的值

常见误用:以为 co_await std::this_thread::sleep_for(...) 合法——其实不行,因为 sleep_for 不是可等待对象。你需要包装成 timer_awaitable 或用支持协程的异步 I/O 库(如 asio::steady_timer::async_wait)。

co_yield 本质是 co_await promise.yield_value(...)

它只对生成器类协程有意义(比如想实现类似 Python 的 yield)。

  • 触发 promise_type::yield_value(value),这个函数必须返回一个 awaitable
  • 典型实现中,yield_valuevalue 存入缓冲区,返回一个始终就绪(await_ready() == true)的 awaitable,保证每次 co_yield 后立即返回控制权给调用方
  • std::generator(C++23)就是基于这套机制,但它的 promise_type 是标准定义的,不可直接用于 C++20

注意:co_yield 不能用在返回 task 这类“单次返回”语义的协程里——编译器会报错,因为对应 promise_type 没有 yield_value 成员。

调试协程时最常忽略的点

协程栈不是传统调用栈:挂起后局部变量存在 coroutine frame 里(堆或栈上,取决于分配策略),不会随函数返回销毁。但这也意味着:

  • 如果 awaiter 在 await_suspend 中保存了 coroutine_handle 却忘了调用它(比如 timer 到期后没 resume),协程就永久挂起,无任何错误提示
  • co_yieldco_await 后的代码可能跨多次调用才执行,别在其中放依赖单次执行顺序的副作用(如全局计数器递增)
  • 异常传播路径变复杂:unhandled_exception() 在 promise 里捕获,但若你没重写它,默认会调用 std::terminate()

没有运行时协程调度器(如 asio 的 io_context 或手动写的线程池),co_await 只是语法糖,不会自动并发——这点比 Go 的 goroutine 或 Rust 的 async/await 更底层、也更易出错。