微软连个名字都不会起
#47
Replies: 1 comment
-
|
深有同感, 我觉得就是因为微软家的编译器实现了这套东西, c++ 标准委员会看人家来头大, 就吱吱唔唔都不说话了 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
微软不会起名，而且名字还具有极大的误导性。
先说类名：
首先，微软的协程原作者，他总是用 Task<> 来命名一个协程函数。但是这就是他犯的第一个错误。
因为只有 await 构成的一系列调用，那条调用链才是一个 “任务”。 也就是 asio 作者所说的 co_spawn. 只有被 spawn 出来的协程，才叫一个任务。而被 await 的函数，不能叫任务，而是”可异步等待返回的函数“。 因此 asio 作者使用 asio::awaitable<> 来命名，而不是 task<> 是十分妥帖的。
接着是 promise_type ，这个微软就是纯粹的瞎搞了。不同于 Task<> 只是出现在微软的示例代码里，promise_type 可是直接进了标准。这瞎命名带来的恶劣影响要大的多。为啥说这个不能是 promise_type 呢？ 因为这个对象存储的是 协程状态。因此 asio 使用 coro_frame 来命名，显然要更正确的。它存储的就是当前协程帧的状态数据。
最后是 final_suspend ，这个类名简直就是严重误导性的集大成者。他干的活和 suspend 毫无关系。实际上他干的恰恰不是 suspend 的活，而是 “恢复调用者” 。协程作为可等待函数，他的调用者调用了一个协程后，调用者才是真正的被 suspend 了。被调用者是执行中。处于 running 状态。当被调用者完成工作，他要 恢复 调用者，让调用者醒来继续干活。
因此， final_suspend 其实应该叫 resume_caller .
接着说 三件套函数名：
await_suspend 其实不是 挂起。协程 A 调用 协程 B, 实际上是 A 被挂起。可是代码上却是 调用 B 的 await_suspend 。这简直就是极大的误导性。当 B 对象的 await_suspend 被调用的时候，实际上恰恰是 B 被 “恢复”， B 进入了 running 状态。这个地方准确的命名，应该叫 await_setup.
await_resume 实际上不是继续。协程 B 返回给 协程 A 的时候，实际上是 协程B 完工了。恢复的其实是 A. 但是恢复 A ，调用的却是 B 的 await_resume , 这简直就是胡扯一样的名字。 应该叫 await_result ，拿到 await 结果了。
await_ready 意思其实是反过来的。而且具有极大的误导性。实际上这个 await_ready 的存在价值为 0 。 毫无意义。
还有存在于 promise_type 里的 三件套函数名：
initial_suspend/final_suspend 设计简直就是毒瘤。更正确的设计，应该是把这种东西和 awaitable 放一起。promise_type， 或者说 coro_frame , 就单纯的作为一个 “数据存储” 对象。不要携带干活的代码。虽然 c++ 的对象是数据+代码。但是这个 数据上捆绑的代码，更多的是为了实现 RAII ，而不是真的乱来，随便给代码找个对象安上。
initial_suspend 的活，应该提到 await_setup 里合并工作。 final_suspend 改到 awaitable::await_done 里完成恢复。
Beta Was this translation helpful? Give feedback.
All reactions