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

Question

有几个问题涵盖了std::enable_shared_from_this 的行为，但我不认为这是重复的。

从std::enable_shared_from_this 继承的类带有std::weak_ptr 成员。当应用程序创建一个指向std::enable_shared_from_this 子类的std::shared_ptr 时，std::shared_ptr 构造函数会检查std::weak_ptr，如果它没有被初始化，则初始化它并使用std::weak_ptr 控制块来控制std::shared_ptr .但是，如果 std::weak_ptr 已经初始化，构造函数只会创建一个带有新控制块的新 std::shared_ptr。当两个std::shared_ptr 实例之一的引用计数变为零并删除底层对象时，这会使应用程序崩溃。

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

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

// Okay, p1 and p2 both have ref count = 2
std::shared_ptr<C> p2 = p->shared_from_this();

// Bad: p3 has ref count 1, and C will be deleted twice
std::shared_ptr<C> p3(p);

我的问题是：为什么图书馆会这样？如果std::shared_ptr 构造函数知道该对象是std::enable_shared_from_this 子类并费心检查std::weak_ptr 字段，为什么它不总是为新的std::shared_ptr 使用相同的控制块，从而避免潜在的崩溃？

那么，为什么 shared_from_this 方法在 std::weak_ptr 成员未初始化时会失败，而不是仅仅初始化它并返回 std::shared_ptr？

这个库的工作方式似乎很奇怪，因为它在很容易成功的情况下失败了。我想知道是否有我不理解的设计注意事项/限制。

我在 C++17 模式下使用 Clang 8.0.0。

Answer 1

如果我正确理解您的问题，您会认为第二次调用构造函数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 的类的实现，它是已定义或未定义的行为。每次都将其设为 undefined 会更容易混淆。

enable_shared_from_this 是在没有shared_ptr 的情况下获取shared_ptr 的标准解决方法。一个经典的例子：

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

     NonCopyable nc;
 };

添加您提到的额外功能确实会在您不需要时添加额外代码，仅用于检查。不过，这并不重要，零开销抽象并不是几乎零开销抽象。

Answer 2

这不是对问题的回答，而是对用户 jvapen 的回复，基于他对这个问题的回答。

您在回答中已经说明了这一点：

struct C {};

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

我在这里没有看到第 5 行 std::shared_ptr<C> p3(p); 现在是一个错误。根据cppreference:shared_ptr，他们明确指出：

std::shared_ptr 是一个智能指针，它通过指针保持对象的共享所有权。多个shared_ptr 对象可能拥有同一个对象。

Answer 3

为同一个指针创建两个shared_ptrs 是未定义的行为，与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);

Answer 4

创建一个实际上不拥有的辅助智能指针（当最后一个副本被重置/销毁时它什么都不做），或者在控制块中（在删除器对象中）携带原始智能指针的副本，这样当次要引用计数变为零主要引用计数减少，这是一种非常罕见的情况，可能会让大多数程序员感到困惑，但它本质上并不是非法的。 （而且我认为在特殊情况下可以为这种模式提供强有力的理由。）

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