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.3.2.2.2 [util.smartptr.shared.const] Status: Resolved Submitter: Peter Dimov Opened: 2008-04-11 Last modified: 2016-01-28

Priority: Not Prioritized

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

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(i))

[ 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 EditorialResolved. Solved by N2994.

Proposed resolution:

Change 20.3.2.2 [util.smartptr.shared] and 20.3.2.2.2 [util.smartptr.shared.const]: 

constexpr shared_ptr();

Change 20.3.2.3 [util.smartptr.weak] and 20.3.2.3.2 [util.smartptr.weak.const]: 

constexpr weak_ptr();

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

constexpr enable_shared_from_this();