- 主题:deducing this是lambda coroutine lifetime issue的解决方法吗
查了一下c++23 standard，感觉这是compiler的一个bug，或者compiler没有fully comply with c++23
[stmt.return.coroutine] (9.6.4)
This section governs how the state of a coroutine is preserved across suspension points. It explicitly states that all local variables (including lambda captures) are preserved in the coroutine frame.
【 在 ziqin 的大作中提到: 】
: 这个问题只能说c++23只是一个tick，不是tock版本，很多设计没有考虑全面
: 你这个问题的本质是，如果coroutine是一个functor，到底哪些算coroutine的state，很明显，在现在的版本里，capture的部分不属于coroutine的state，因为它们是functor struct的data member
: c++标准在推进的时候，基本都是先考虑free function情况，再推广到lambda和template上
: ...................
--
修改:ziqin FROM 115.193.191.*
FROM 115.193.191.*
你想拿coroutine干啥，没必要为了coroutine而coroutine，要针对你的应用目标去寻找工具。
【 在 allegro 的大作中提到: 】
: 如果lambda返回一个coroutine，并且这个lambda有capture，那一般会有lifetime issue。
: 当lambda被销毁后，它的capture list也没了。
: 所以当返回的coroutine被resume时候，就触发了use-after-free。
: ...................
--
FROM 221.221.55.*
coroutine作为语法糖，要比普通的函数调用开销大的多。
在异步和并行计算方面，多核系统中，远不如多线程高效。
【 在 ylh1969 的大作中提到: 】
: 你想拿coroutine干啥，没必要为了coroutine而coroutine，要针对你的应用目标去寻找工具。
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
其实不会。不存在开销大得多这种说法。
c++20 实现的 stackless coroutine. 相当于在生成函数的时候，额外传入个 context 作为参数而已。和 lambda capture 变量是一样的啊。
【 在 ylh1969 的大作中提到: 】
: coroutine作为语法糖，要比普通的函数调用开销大的多。
: 在异步和并行计算方面，多核系统中，远不如多线程高效。
--
FROM 110.84.120.*
开销会大一些，不会大太多，主要还是因为context是存在heap上的，需要动态分配内存。lambda还是在stack上的。
主要还是为了代码可读性，大家写异步代码的时候总还是希望逻辑连贯的，别是是现在异步调用越来越多。
f()
{
# logic 1
# wait 1
# logic 2
# wait 2
}
以往自己写callback的时候，需要自己管理各种context，现在只要管一个coroutine handler就可以了。
【 在 hgoldfish 的大作中提到: 】
: 其实不会。不存在开销大得多这种说法。
: c++20 实现的 stackless coroutine. 相当于在生成函数的时候，额外传入个 context 作为参数而已。和 lambda capture 变量是一样的啊。
:
--
FROM 115.193.214.*
stackless后续函数调用很麻烦的，尤其是后边第三方软件，如大型数据库的调用，没有方法预估栈使用量。
【 在 hgoldfish 的大作中提到: 】
: 其实不会。不存在开销大得多这种说法。
: c++20 实现的 stackless coroutine. 相当于在生成函数的时候，额外传入个 context 作为参数而已。和 lambda capture 变量是一样的啊。
:
--
FROM 221.221.55.*