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.
Section: 220.127.116.11.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.
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. Solved by N2994.
Change 18.104.22.168 [util.smartptr.shared] and 22.214.171.124.2 [util.smartptr.shared.const]:
Change 126.96.36.199 [util.smartptr.weak] and 188.8.131.52.2 [util.smartptr.weak.const]:
Change 184.108.40.206 [util.smartptr.enab] (2 places):