class Base : public std::enable_shared_from_this<Base> {
public:
    template<class T>
        requires std::is_base_of_v<Base, T>
    std::shared_ptr<T> shared_from_this_cast() {

        return std::static_pointer_cast<T>(shared_from_this());
    }

    template<class T>
        requires std::is_base_of_v<Base, T>
    std::shared_ptr<const T> shared_from_this_cast() const {

        return std::static_pointer_cast<const T>(shared_from_this());
    }

    virtual void call() {
        std::cout << "Base" << std::endl;
    }
    virtual void process() = 0;
};

class A :  public Base {
    void call() override {
        std::cout << "A" << std::endl;
    }
    void process() override {
        auto ptr = shared_from_this_cast<A>();
        auto task = [ptr]() { ptr->task_only_A(); };
        //asio::post(context, task);
    }
    void task_only_A() {}

};
class B : public  Base {
    void call() override {

        std::cout << "B" << std::endl;
    }
    void process() override {
        auto ptr = shared_from_this_cast<B>();
        auto task = [ptr]() {ptr->task_only_B(); };
        //asio::post(context, task);
    }
    void task_only_B() {}
};

类似上面这种，因为要异步调用 各个子类的特有task函数，而且子类要shared_from_this() , 所以在函数都要
shared_from_this_cast<>，静态指定转化的类

希望子类具有多态，但是又是必须编译转为静态，有点脱屁股放屁的感觉，明明都是自己的业务逻辑，直接分开各个类，不继承好像也可以。因为有个父类，这里 父类纯粹就是 规划一些 统一的接口罢了。
--
修改:Algoquant FROM 14.154.47.*
FROM 14.154.47.*

我这里chatgpt给了三个思路



--
FROM 114.254.115.*

主要是因为异步任务的生命周期管理的问题，不用shared_from_this，除非你写一个全局的任务管理器，不然在程序结束析构的，不知道任务是否完成
--
FROM 115.192.190.*

确实是

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

由于都是单例，this指针无需转为shared_ptr，只要保证初始化、停止的顺序就行。


【 在 ziqin 的大作中提到: 】
: 主要是因为异步任务的生命周期管理的问题，不用shared_from_this，除非你写一个全局的任务管理器，不然在程序结束析构的，不知道任务是否完成
--
FROM 114.254.115.*

chatgpt回复你这句：

这个说法在某些上下文中有一定道理，但不能一概而论地说“不要用 shared_ptr”。我们可以拆开来看：

? 这个说法有合理之处：
shared_ptr 确实会造成所有权不清晰

shared_ptr 是共享所有权的智能指针，多个对象都可以持有它的副本，这就使得“谁负责释放资源”变得模糊。

在复杂系统中，很容易出现循环引用（比如 A 拿 B 的 shared_ptr，B 也拿 A 的），导致内存泄漏。

在调试资源生命周期时，shared_ptr 也不如 unique_ptr 直观。

资源生命周期控制复杂

如果滥用 shared_ptr，程序结构就变得像“垃圾回收”，缺乏明确的资源释放时机，降低性能，增加 bug 风险。

某些架构下更推荐组合使用 unique_ptr + 明确责任管理

比如：构造函数注入、工厂模式、RAII 等。

? 但完全说“不要用 shared_ptr”是不合理的：
shared_ptr 设计出来就是为了解决需要多个地方持有资源的场景，比如：

观察者模式：多个观察者都需要访问同一个对象。

资源缓存系统：资源由多个子系统共享，自动引用计数释放。

任务系统/图调度系统：多个任务可能持有对同一资源的引用。

合理使用 shared_ptr 并不会降低代码质量，关键是：

明确其使用目的（必须共享才用，不要用来“偷懒”传对象）

注意避免循环引用（可以用 weak_ptr 打破环）

? 最佳实践建议：

场景    推荐使用
唯一所有权、明确责任    unique_ptr（优先）
需要共享资源    shared_ptr
可能打破循环引用    weak_ptr
短生命周期对象    裸指针或引用传参，不持有

总结一句话：
架构师的出发点是好的，但“完全不用 shared_ptr”是走向另一个极端。关键是 清晰设计所有权语义，而不是完全禁止某种工具。

如果你愿意，可以贴你们项目中遇到的例子，我可以帮你分析这个地方该用什么指针更合适。

【 在 tortelee 的大作中提到: 】
: 我们的架构强烈要求我们不要用sharedptr，因为他导致，所有权不清晰。能不用，就别用。
--
FROM 114.254.115.*