This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 126.96.36.199 [unique.ptr.dltr] Status: C++11 Submitter: Daniel Krügler Opened: 2009-08-18 Last modified: 2017-02-03
Priority: Not Prioritized
View all issues with C++11 status.
According to the general rules of 188.8.131.52 [res.on.functions] p 2 b 5 the effects are undefined, if an incomplete type is used to instantiate a library template. But neither in 184.108.40.206 [unique.ptr.dltr] nor in any other place of the standard such explicit allowance is given. Since this template is intended to be instantiated with incomplete types, this must be fixed.
[ 2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
[ 2009-11-17 Alisdair Opens: ]
LWG 1193 tries to support unique_ptr for incomplete types. I believe the proposed wording goes too far:
The template parameter T of default_delete may be an incomplete type.
Do we really want to support cv-void? Suggested ammendment:
The template parameter T of default_delete may be an incomplete type .
We might also consider saying something about arrays of incomplete types.
Did we lose support for unique_ptr<function-type> when the concept-enabled work was shelved? If so, we might want a default_delete partial specialization for function types that does nothing. Alternatively, function types should not be supported by default, but there is no reason a user cannot support them via their own deletion policy.
Function-type support might also lead to conditionally supporting a function-call operator in the general case, and that seems way too inventive at this stage to me, even if we could largely steal wording directly from reference_wrapper. shared_ptr would have similar problems too.
[ 2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
Add two new paragraphs directly to 220.127.116.11 [unique.ptr.dltr] (before 18.104.22.168.2 [unique.ptr.dltr.dflt]) with the following content: