enable_shared_from_this 典型使用场景

enable_shared_from_this

enable_shared_from_this 是个CRTP模板类，提供了一个可以返回一个shared_ptr的接口，源码也很简单，就是根据weak_ptr构造一盒shared_ptr。当然这就引出很重要的一点就是，能够调用shared_from_this（）的对象，必须是shared_ptr 管理的对象，不能是裸指针对象。

简单明了的作用，就是可以在类成员函数内部，返回一个shared_ptr对象。
因为直接调用shared_ptr(*this)会存在double free的问题。
但是我们什么时候需要这个功能呢？

一个具体的例子

我这边有一个定时器类timer 类，具体细节就不细表了，简单如下。

• timer类，作为做为外部调用接口类，外部使用者创建timer，并且设置回调，事件周期、oneshot与否之类的
• mannger类，作为内部管理类，创建线程池来作为执行定时器回调的执行者。mannager会自动添加timer类对象到自己内部。

假设现在我们有一个使用者类对象a，持有一个timer类。

class User{
public:
	void setTimer(){
	timer->setCallBack([this](){
		std::cout << a << b << "\n";
	})
	timer.setPeriod(1000ms);
	}
private:
 shared_ptr<Timer> time;
 int a;
 int b
}

int main(){
	auto user = make_shared<User>();
	user.setTimer();
	user.reset();
}

上述代码可以预见是有问题的，因为user.reset()，之后user对象被释放了，但是timer的回调还在，仍通过捕获的this在调用成员变量，这就导致crash的问题。

当然，接手的这块的代码写的非常严谨，毕竟经过量产的东西，mannager执行callback的时候使用各种标志位判断对象是否析构，同时timer的析构也通过标志位去loop避免callback与对象析构之间的同步关系，巴拉巴拉写了一堆复杂的逻辑。

但是其实这就是典型的enable_shared_from_this的使用场景，可以取代这一堆复杂的逻辑判断。

class User : public enable_shared_from_this<User>{
public:
	void setTimer(){
	timer->setCallBack([user = this->shared_from_this()](){
		std::cout << user.a << user.b << "\n";
	})
	timer.setPeriod(1000ms);
	}
private:
 shared_ptr<Timer> time;
 int a;
 int b
}

因为我们调用的时shared_from_this,相当于user对象引用计数+1了，这样即使我们外部调用user.reset(），mannager调用callback时仍持有一份user引用，并不会导致对象析构，确保在callback期间对象的正常调用。
这样mannger、timer里的一堆繁琐复杂的对象判断就都可以全删了。

作用总结

从以上例子我们也可以得出结论：
作用两个字概括：保活
作用四个字概括：对象保活
作用八个字概括：对象异步调用保活

虽然c++在一些现代化版本（11+）已经提供了shared_ptr/unique_ptr智能指针极大的降低了C++er操作指针的心智负担。但是在一个异步调用时仍然存在问题；

如上例子，user这个对象是用shared_ptr，我们可以放心大胆的使用指针，但是setTimer，这个成员函数内部，shared_ptr这种引用计数的规则在callback这里被打破了，在成员函数内我们不知道对象本身是哪个对象，我们能够获取的只有this指针，直接使用this裸指针必然又引入了析构问题。

在这种场景下，enable_shared_from_this就诞生了，提供了成员函数内部异步调用的对象引用计数连续，内存的生命周期控制又回到了引用计数。