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)?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With