Question

Code:

#include <memory>
using namespace std;

struct T {};

T* foo() { return new T; }
T const* bar() { return foo(); }

int main()
{
    unique_ptr< T const >       p1( bar() );        // OK
    unique_ptr< T const [] >    a1( bar() );        // OK

    unique_ptr< T const >       p2( foo() );        // OK
    unique_ptr< T const [] >    a2( foo() );        // ? this is line #15
}

Example errors with Visual C++ 10.0 and MinGW g++ 4.4.1:

[d:\dev\test]
> cl foo.cpp
foo.cpp
foo.cpp(15) : error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>'
        with
        [
            _Ty=const T []
        ]
        C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\memory(2509) : see declaration of 'std::unique_ptr<_Ty>::unique_ptr'
        with
        [
            _Ty=const T []
        ]

[d:\dev\test]
> g++ foo.cpp -std=c++0x
c:\program files (x86)\codeblocks\mingw\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/unique_ptr.h: In function 'int main()':
c:\program files (x86)\codeblocks\mingw\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/unique_ptr.h:379: error: deleted function 'std::unique_ptr<_Tp [], _Tp_Deleter>::unique_ptr(_Up*, typename std::enable_if<std::is_convertible::value, void>::type*) [with _Up = T, _Tp = const T, _Tp_Deleter = std::default_delete<const T []>]'
foo.cpp:15: error: used here

[d:\dev\test]
> _

It seems to me that the array version should accept the same implicit const-adding as the non-array version.

The difference is that the array version should not accept pointer to a derived class, and that’s the machinery that apparently kicks in above.

Is the code valid?

If the code is formally invalid, does the standard’s wording reflect the intent (i.e., is a DR appropriate)?

If no to the first and yes to the second, is the intent defective (i.e., again, is a DR appropriate)?

Answer 1

A defect report may be appropriate. §20.7.1.3.1 says,

explicit unique_ptr(pointer p) noexcept;
unique_ptr(pointer p, see below d) noexcept;
unique_ptr(pointer p, see below d) noexcept;

These constructors behave the same as in the primary template except that they do not accept pointer types which are convertible to pointer. [Note: One implementation technique is to create private templated overloads of these members. — end note ]

The idea is clearly to prevent derived-to-base conversions that don’t work with arrays. But it is unspecific and cv-qualification conversion is forbidden too. Perhaps it should be changed to forbid pointer conversions (§4.10), not all conversions of pointers.