有管理需求就有性能损耗，asio的executor，或者能看到的广泛使用的executor都没有设计任务队列管理功能

我猜原因大概是因为任务队列管理这块里有太多的用户定制需求，有些情况下，需要post到队列里的任务全部完成，有些需要cancel没有开始执行的，继续执行已经在执行的，有些需要按条件cancel，按c++的设计思路，这块肯定是需要用户自己写一个全局的任务管理器



【 在 z16166 的大作中提到: 】
: 确实是
: 我现在有个程序只有单例类（模块类）才会向也是单例类的executor（线程池）post任务过去，
: 程序初始化时最先初始化executor，程序结束前要最先停掉executor（不接受新任务，等待已经提交的任务执行完，但executor的this指针并不在这个时候销毁），防止它还在引用别的单例类的this指针。
: ...................
--
FROM 115.192.190.*

gpt的回答有点同鸡讲鸭了

shared_from_this的核心，是shared，不是common interface。换成人话就是说，executor在执行一个异步任务以后，需要继续把这个object post到队列里执行等待后续的异步回应，这个操作需要要求这个object在后续异步回应到达的时候还存在，那么怎么保证，要么有一个全局的object管理器，要么这个object是个shared_ptr从自己生成一个。显然从自己copy一个或者从自己move出一个有很大的开销和风险，所以多一个shared_from_this()的接口


【 在 z16166 的大作中提到: 】
: 有些截图软件支持滚动截屏，FarStone Capture之类的，截了后按pagedown键向下翻页选中需要的区域，复制到画笔里存盘。
: Chrome自带的截屏功能不如这个。
: chatgpt提到的这个type erasure有点意思
: ...................
--
FROM 115.192.190.*

最近看到了百度的apollo中ComponentBase，也是用到了std::enabled_shared_from_this，看得头大
【 在 Algoquant 的大作中提到: 】
: class Base : public std::enable_shared_from_this<Base> {
: public:
:     template<class T>
: ...................
--
FROM 117.37.8.*