blocks|key|3937902|text|创建两个指向同一指针的shared_ptr是未定义的行为，与std::enable_shared_from_this无关。你的代码应该是：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3937903|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);|code-block|syntax|javascript|3937904|entityMap^0|B|A|U|S|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

Creating two <code>shared_ptr</code>s to the same pointer is undefined behaviour and is nothing to do with <code>std::enable_shared_from_this</code>. Your code should be:

<pre><code>struct C : std::enable_shared_from_this&lt;C&gt; {};

C *p = new C();
std::shared_ptr&lt;C&gt; p1(p);

std::shared_ptr&lt;C&gt; p2 = p-&gt;shared_from_this();

std::shared_ptr&lt;C&gt; p3(p1);
</code></pre>

blocks|key|3938077|text|如果我正确理解了您的问题，您可能会认为第二次调用构造函数shared_ptr将在逻辑上重用存储在shared_from_this中的控制块。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3938078|从您的角度来看，这似乎是合乎逻辑的。让我们暂时假设C是您正在维护的库的一部分，并且C的使用是您的库的用户的一部分。|3938079|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|code-block|syntax|javascript|3938080|现在，您找到了一种不再需要enable_shared_from_this的方法，并且在您的库的下一个版本中，它将更新为：|3938081|struct+C+{};

C+*p+=+new+C();
std::shared_ptr<C>+p1(p);
std::shared_ptr<C>+p3(p);+//+Now+a+bug|3938082|突然之间，完全有效的代码变得无效，没有任何编译器错误/警告，因为升级了你的库。在可能的情况下，应该防止这种情况发生。|3938083|同时，它也会造成很多混乱。原因取决于您放在shared_ptr中的类的实现，它要么是定义的行为，要么是未定义的行为。每次都将其设置为未定义，这样就不那么容易混淆了。|3938084|如果您没有shared_ptr，enable_shared_from_this是获得shared_ptr的标准解决方法。一个经典的例子：|3938085|+struct+C+:+std::enable_shared_from_this<C>
+{
+++++auto+func()
+++++{
+++++++++return+std::thread{[c+=+this->shared_from_this()]{+/*Do+something*/+}};
+++++}

+++++NonCopyable+nc;
+};|3938086|添加你提到的额外功能确实会在你不需要的时候添加额外的代码，只是为了检查。不过，这并不重要，零开销抽象并不是几乎零开销抽象。|3938087|entityMap^0|S|A|0|P|1|15|1|0|0|D|N|0|0|0|0|5|A|G|N|16|A|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|1A|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|O|3|P|5|J|7|1E|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1F|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1G|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1H|8|@$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|W|3|X|5|J|7|1O|8|@]|D|@]|E|$K|L]]|$1|Y|3|Z|5|6|7|1P|8|@]|D|@]|E|$]]|$1|10|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]]|11|$]]

If I understand your question correctly, you would assume that calling the constructor <code>shared_ptr</code> a second time would logically reuse the control block stored in shared_from_this.

From your point of view, this looks logical. Let's assume for a moment that <code>C</code> is part of a library your are maintaining and the usage of <code>C</code> is part of a user of your library.

<pre><code>struct C : std::enable_shared_from_this&lt;C&gt; {};

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

Now, you found a way to no longer need the <code>enable_shared_from_this</code> and in the next version of your library, this gets updated to:

<pre><code>struct C {};

C *p = new C();
std::shared_ptr&lt;C&gt; p1(p);
std::shared_ptr&lt;C&gt; p3(p); // Now a bug
</code></pre>

Suddenly, perfectly valid code becomes invalid without any compiler error/warning, because of upgrading your library. Where possible this should be prevented.

At the same time, it will cause a lot of confusion. Cause depending on the implementation of the class you put in shared_ptr, it's either defined or undefined behavior. It's less confusing to make it undefined every single time.

<code>enable_shared_from_this</code> is a standard workaround for getting a hold of a <code>shared_ptr</code> if you don't have a <code>shared_ptr</code>. A classic example:

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

 NonCopyable nc;
 };
</code></pre>

Adding your mentioned extra functionality does add extra code whenever you don't need it, just for the check. Not that it would matter that much, though, zero overhead abstractions ain't nearly zero overhead abstractions.

blocks|key|3938299|text|创建一个实际上不拥有的辅助智能指针(当最后一个副本被重置/销毁时，它什么也不做)，或者在控制块中携带原始智能指针的副本(在deleter对象中)，以便当辅助引用计数变为零时，主引用计数递减，这是非常罕见的情况，可能会使大多数程序员感到困惑，但它本身并不是非法的。(我认为在特殊情况下可以很好地支持这种模式。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3938300|另一方面，存在shared_from_this强烈表明只有一个拥有shared_ptr，因此当预期有多组shared_from_this时，可能应该避免使用std::shared_ptr。与std::enable_shared_from_this的隐式行为不同，显式管理自引用非所属指针更安全，因为它使此类问题在用户代码中变得明显。|offset|length|style|CODE|3938301|entityMap^0|0|7|G|X|A|1G|G|26|F|2N|S|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]|$D|T|E|U|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$]]

Creating a secondary smart pointer that is either actually non owning (it does nothing when the last copy is reset/destroyed), or carries a copy of the original smart pointer in the control block (in the deleter object) such that when the secondary reference count goes to zero the primary refcount is decremented, is a very rare occurrence and would probably be confusing for most programmers, but it isn't inherently illegal. (And I think one can make a strong case for that pattern in special cases.)

On the other hand, the existence <code>shared_from_this</code> strongly suggests that there is only one owning <code>shared_ptr</code>, and so having <code>shared_from_this</code> should probably be avoided when multiple sets of <code>std::shared_ptr</code> are expected. Explicit management of self referential non owning pointers is safer as it makes such issues evident in user code, unlike the implicit behavior of <code>std::enable_shared_from_this</code>.

There are several questions that cover the behavior of <code>std::enable_shared_from_this</code>, but I don't think that this is a duplicate.

Classes that inherit from <code>std::enable_shared_from_this</code> carry a <code>std::weak_ptr</code> member. When the application creates a <code>std::shared_ptr</code> pointing to a subclass of <code>std::enable_shared_from_this</code>, the <code>std::shared_ptr</code> constructor checks the <code>std::weak_ptr</code>, and if it is not initialized, initializes it and uses the <code>std::weak_ptr</code> control block for the <code>std::shared_ptr</code>. However, if the <code>std::weak_ptr</code> is already initialized, the constructor just creates a new <code>std::shared_ptr</code> with a new control block. This sets the application up to crash when the reference count of one of the two <code>std::shared_ptr</code> instances goes to zero and deletes the underlying object.

<pre><code>struct C : std::enable_shared_from_this&lt;C&gt; {};

C *p = new C();
std::shared_ptr&lt;C&gt; p1(p);

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

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

My question is: why does the library behave this way? If the <code>std::shared_ptr</code> constructor knows that the object is a <code>std::enable_shared_from_this</code> subclass and bothers to check the <code>std::weak_ptr</code> field, why doesn't it always use same control block for the new <code>std::shared_ptr</code>, thus avoiding a potential crash?

And for that matter, why does the method <code>shared_from_this</code> fail when the <code>std::weak_ptr</code> member is not initialized, instead of just initializing it and returning a <code>std::shared_ptr</code>?

It seems strange that the library works the way that it does, since it fails in situations when it could easily succeed. I'm wondering if there were design considerations/limitations that I don't understand.

I am using Clang 8.0.0 in C++17 mode.

Why does std::enable_shared_from_this allow multiple std::shared_ptr instances?

编译器

有几个问题涵盖了std::enable_shared_from_this的行为，但我不认为这是重复的。从std::enable_shared_from_this继承的类带有一个std::weak_ptr成员。当应用程序创建指向std::enable_shared_from_this的子类的std::shared_ptr...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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