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.

### 827. `constexpr shared_ptr::shared_ptr()?`

Section: 20.11.3.2 [util.smartptr.shared.const] Status: Resolved Submitter: Peter Dimov Opened: 2008-04-11 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [util.smartptr.shared.const].

View all issues with Resolved status.

Discussion:

Would anyone object to making the default constructor of `shared_ptr` (and `weak_ptr` and `enable_shared_from_this`) `constexpr`? This would enable static initialization for `shared_ptr` variables, eliminating another unfair advantage of raw pointers.

[ San Francisco: ]

> It's not clear to us that you can initialize a pointer with the literal 0 in a constant expression. We need to ask CWG to make sure this works. Bjarne has been appointed to do this.

> Core got back to us and assured as that `nullptr` would do the job nicely here.

[ 2009-05-01 Alisdair adds: ]

> I don't believe that `constexpr` will buy anything in this case. `shared_ptr/weak_ptr/enable_shared_from_this` cannot be literal types as they have a non-trivial copy constructor. As they do not produce literal types, then the `constexpr` default constructor will not guarantee constant initialization, and so not buy the hoped for optimization.

> I recommend referring this back to Core to see if we can get static initialization for types with `constexpr` constructors, even if they are not literal types. Otherwise this should be closed as NAD.

[ 2009-05-26 Daniel adds: ]

> If Alisdair's 2009-05-01 comment is correct, wouldn't that also make `constexpr mutex()` useless, because this class has a non-trivial destructor? (828)

[ 2009-07-21 Alisdair adds: ]

> The feedback from core is that this and similar uses of `constexpr` constructors to force static initialization should be supported. If there are any problems with this in the working draught, we should file core issues.

> Recommend we declare the default constructor `constexpr` as the issue suggests (proposed wording added).

[ 2009-10 Santa Cruz: ]

> NAD Editorial Resolved. Solved by N2994.

Proposed resolution:

Change 20.11.3 [util.smartptr.shared] and 20.11.3.2 [util.smartptr.shared.const]:

>     constexpr shared_ptr();

Change 20.11.4 [util.smartptr.weak] and 20.11.4.2 [util.smartptr.weak.const]:

>     constexpr weak_ptr();

Change 20.11.6 [util.smartptr.enab] (2 places):

>     constexpr enable_shared_from_this();