This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
enable_shared_from_this::__weak_this
twiceSection: 20.3.2.7 [util.smartptr.enab] Status: Resolved Submitter: Jonathan Wakely Opened: 2015-08-26 Last modified: 2020-09-06
Priority: 3
View all other issues in [util.smartptr.enab].
View all issues with Resolved status.
Discussion:
It is unclear what should happen if a pointer to an object with an
enable_shared_from_this
base is passed to two different shared_ptr
constructors.
#include <memory> using namespace std; int main() { struct X : public enable_shared_from_this<X> { }; auto xraw = new X; shared_ptr<X> xp1(xraw); // #1 { shared_ptr<X> xp2(xraw, [](void*) { }); // #2 } xraw->shared_from_this(); // #3 }
This is similar to LWG 2179(i), but involves no undefined behaviour due
to the no-op deleter, and the question is not whether the second
shared_ptr
should share ownership with the first, but which shared_ptr
shares ownership with the enable_shared_from_this::__weak_this
member.
std::shared_ptr
implementations the xp2
constructor modifies the __weak_this
member so the last line of the
program throws bad_weak_ptr
, even though all the requirements on the
shared_from_this()
function are met (20.3.2.7 [util.smartptr.enab])/7:
Requires:
enable_shared_from_this<T>
shall be an accessible base class ofT
.*this
shall be a subobject of an objectt
of typeT
. There shall be at least oneshared_ptr
instancep
that owns&t
.
Boost doesn't update __weak_this
, leaving it sharing with xp1
, so the
program doesn't throw. That change was made to boost::enable_shared_from_this
because
someone reported exactly this issue as a bug, see Boost issue 2584.
std::shared_ptr
implementations. We should
specify the behaviour of enable_shared_from_this
more precisely, and
resolve this issue one way or another.
[2016-03-16, Alisdair comments]
This issues should be closed as Resolved
by paper p0033r1 at Jacksonville.
Proposed resolution: