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.

### 2505. `auto_ptr_ref` creation requirements underspecified

Section: 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*`.

For example, I expect formation of the `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)`.

There is nothing in the specification of

>     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*`.

The implementation in question uses the `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).

> 1. Change 99 [auto.ptr.conv] as indicated:

>    >     template<class Y> operator auto_ptr_ref<Y>() throw();

>    > > -?- Requires: `X*` can be implicitly converted to `Y*`.

>    > > -3- Returns: An `auto_ptr_ref<Y>` that holds `*this`.

>    > > -?- Notes: Because `auto_ptr_ref` is present for exposition only, the only way to invoke this function is by calling one of the `auto_ptr` conversions which take an `auto_ptr_ref` as an argument. Since all such conversions will call `release()` on `*this` (in the form of the `auto_ptr` that the `auto_ptr_ref` holds a reference to), an implementation of this function may cause instantiation of said `release()` function without changing the semantics of the program.

>    >     template<class Y> operator auto_ptr<Y>() throw();

>    > > -?- Requires: `X*` can be implicitly converted to `Y*`.

>    > > -4- Effects: Calls `release()`.

>    > > -5- Returns: An `auto_ptr<Y>` that holds the pointer returned from `release()`.

[2016-08 - Chicago]

Thurs AM: Moved to Tentatively Resolved

Proposed resolution:

Resolved by acceptance of N4190.