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.

### 2179. `enable_shared_from_this` and construction from raw pointers

Section: 20.3.2.5 [util.smartptr.enab], 20.3.2.2.2 [util.smartptr.shared.const] Status: Resolved Submitter: Daniel Krügler Opened: 2012-08-16 Last modified: 2017-09-07

Priority: 3

View all other issues in [util.smartptr.enab].

View all issues with Resolved status.

Discussion:

On reflector message c++std-lib-32927, Matt Austern asked whether the following example should be well-defined or not

>     struct X : public enable_shared_from_this<X> { };
>     auto xraw = new X;
>     shared_ptr<X> xp1(xraw);
>     shared_ptr<X> xp2(xraw);

pointing out that 20.3.2.2.2 [util.smartptr.shared.const] does not seem to allow it, since `xp1` and `xp2` aren't allowed to share ownership, because each of them is required to have `use_count() == 1`. Despite this wording it might be reasonable (and technical possible) to implement that request.

On the other hand, there is the non-normative note in 20.3.2.5 [util.smartptr.enab] p11 (already part of TR1):

> The `shared_ptr` constructors that create unique pointers can detect the presence of an `enable_shared_from_this` base and assign the newly created `shared_ptr` to its `__weak_this member`.

Now according to the specification in 20.3.2.2.2 [util.smartptr.shared.const] p3-7:

>     template<class Y> explicit shared_ptr(Y* p);

the notion of creating unique pointers can be read to be included by this note, because the post-condition of this constructor is `unique() == true`. Evidence for this interpretation seems to be weak, though.

Howard Hinnant presented the counter argument, that actually the following is an "anti-idiom" and it seems questionable to teach it to be well-defined in any case:

>     auto xraw = new X;
>     shared_ptr<X> xp1(xraw);
>     shared_ptr<X> xp2(xraw);

He also pointed out that the current post-conditions of the affected `shared_ptr` constructor would need to be reworded.

It needs to be decided, which direction to follow. If this idiom seems too much broken to be supported, the note could be improved. If it should be supported, the constructors in 20.3.2.2.2 [util.smartptr.shared.const] need a careful analysis to ensure that post-conditions are correct.

Several library implementations currently do not support this example, instead they typically cause a crash. Matt points out that there are currently no explicit requirements imposed on `shared_ptr` objects to prevent them from owning the same underlying object without sharing the ownership. It might be useful to add such a requirement.

[2013-03-15 Issues Teleconference]

Moved to Open.

More discussion is needed to pick a direction to guide a proposed resolution.

[2013-05-09 Jonathan comments]

The note says the newly created `shared_ptr` is assigned to the `weak_ptr` member. It doesn't say before doing that the `shared_ptr` should check if the `weak_ptr` is non-empty and possibly share ownership with some other pre-existing `shared_ptr`.

[2015-08-26 Daniel comments]

LWG issue 2529 is independent but related to this issue.

[2016-03-16, Alisdair comments]

This issues should be closed as `Resolved` by paper p0033r1 at Jacksonville.

Proposed resolution: