问为什么std::enable_shared_from_this允许多个std::shared_ptr实例？

EN

如果我正确理解了您的问题，您可能会认为第二次调用构造函数shared_ptr将在逻辑上重用存储在shared_from_this中的控制块。

从您的角度来看，这似乎是合乎逻辑的。让我们暂时假设C是您正在维护的库的一部分，并且C的使用是您的库的用户的一部分。

struct C : std::enable_shared_from_this<C> {};

C *p = new C();
std::shared_ptr<C> p1(p);
std::shared_ptr<C> p3(p); // Valid given your assumption

现在，您找到了一种不再需要enable_shared_from_this的方法，并且在您的库的下一个版本中，它将更新为：

struct C {};

C *p = new C();
std::shared_ptr<C> p1(p);
std::shared_ptr<C> p3(p); // Now a bug

突然之间，完全有效的代码变得无效，没有任何编译器错误/警告，因为升级了你的库。在可能的情况下，应该防止这种情况发生。

同时，它也会造成很多混乱。原因取决于您放在shared_ptr中的类的实现，它要么是定义的行为，要么是未定义的行为。每次都将其设置为未定义，这样就不那么容易混淆了。

如果您没有shared_ptr，enable_shared_from_this是获得shared_ptr的标准解决方法。一个经典的例子：

 struct C : std::enable_shared_from_this<C>
 {
     auto func()
     {
         return std::thread{[c = this->shared_from_this()]{ /*Do something*/ }};
     }

     NonCopyable nc;
 };

添加你提到的额外功能确实会在你不需要的时候添加额外的代码，只是为了检查。不过，这并不重要，零开销抽象并不是几乎零开销抽象。

创建两个指向同一指针的shared_ptr是未定义的行为，与std::enable_shared_from_this无关。你的代码应该是：

struct C : std::enable_shared_from_this<C> {};

C *p = new C();
std::shared_ptr<C> p1(p);

std::shared_ptr<C> p2 = p->shared_from_this();

std::shared_ptr<C> p3(p1);

创建一个实际上不拥有的辅助智能指针(当最后一个副本被重置/销毁时，它什么也不做)，或者在控制块中携带原始智能指针的副本(在deleter对象中)，以便当辅助引用计数变为零时，主引用计数递减，这是非常罕见的情况，可能会使大多数程序员感到困惑，但它本身并不是非法的。(我认为在特殊情况下可以很好地支持这种模式。)

另一方面，存在shared_from_this强烈表明只有一个拥有shared_ptr，因此当预期有多组shared_from_this时，可能应该避免使用std::shared_ptr。与std::enable_shared_from_this的隐式行为不同，显式管理自引用非所属指针更安全，因为它使此类问题在用户代码中变得明显。