auto_ptr_ref
creation requirements underspecifiedSection: 99 [auto.ptr.conv] Status: Resolved Submitter: Hubert Tong Opened: 2015-05-28 Last modified: 2020-09-06
Priority: 4
View all other issues in [auto.ptr.conv].
View all issues with Resolved status.
Discussion:
In C++14 sub-clause 99 [auto.ptr.conv], there appears to be no requirement that the formation of an
auto_ptr_ref<Y>
from an auto_ptr<X>
is done only when X*
can be implicitly
converted to Y*
.
auto_ptr_ref<A>
from the prvalue of type auto_ptr<B>
to be invalid in the case below (but the wording does not seem to be there):
#include <memory> struct A { }; struct B { } b; std::auto_ptr<B> apB() { return std::auto_ptr<B>(&b); } int main() { std::auto_ptr<A> apA(apB()); apA.release(); }
The behaviour of the implementation in question on the case presented above is to compile and execute it successfully
(which is what the C++14 wording implies). The returned value from apA.release()
is essentially
reinterpret_cast<A*>(&b)
.
template <class X> template <class Y> operator auto_ptr<X>::auto_ptr_ref<Y>() throw();
which implies that X*
should be implicitly convertible to Y*
.
reinterpret_cast
interpretation even when Y
is an accessible,
unambiguous base class of X
; the result thereof is that no offset adjustment is performed.
[2015-07, Telecon]
Marshall to resolve.
[2016-03-16, Alisdair Meredith comments]
This issue is a defect in a component we have actively removed from the standard. I can't think of a clearer example of something that is no longer a defect!
[2016-08-03, Alisdair Meredith comments]
As C++17 removes auto_ptr
, I suggest closing this issue as closed by paper
N4190.
Previous resolution [SUPERSEDED]:
This wording is relative to ISO/IEC 14882:2014(E).
Change 99 [auto.ptr.conv] as indicated:
template<class Y> operator auto_ptr_ref<Y>() throw();-?- Requires:
-3- Returns: AnX*
can be implicitly converted toY*
.auto_ptr_ref<Y>
that holds*this
. -?- Notes: Becauseauto_ptr_ref
is present for exposition only, the only way to invoke this function is by calling one of theauto_ptr
conversions which take anauto_ptr_ref
as an argument. Since all such conversions will callrelease()
on*this
(in the form of theauto_ptr
that theauto_ptr_ref
holds a reference to), an implementation of this function may cause instantiation of saidrelease()
function without changing the semantics of the program.template<class Y> operator auto_ptr<Y>() throw();-?- Requires:
-4- Effects: CallsX*
can be implicitly converted toY*
.release()
. -5- Returns: Anauto_ptr<Y>
that holds the pointer returned fromrelease()
.
[2016-08 - Chicago]
Thurs AM: Moved to Tentatively Resolved
Proposed resolution:
Resolved by acceptance of N4190.