Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Should `unique_ptr< T const [] >` accept a `T*` constructor argument?

Reply
Thread Tools

Should `unique_ptr< T const [] >` accept a `T*` constructor argument?

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      12-16-2011
<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
}
</code>


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


<example>
[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::uni
que_ptr<_Ty>'
with
[
_Ty=const T []
]
C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\memory(2509) : see declaration of 'std::unique_pt
r<_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 mai
n()':
c:\program files
(x86)\codeblocks\mingw\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/unique_ptr.h:379:
error: deleted f
unction '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]
> _

</example>


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)?


Cheers,

- Alf
 
Reply With Quote
 
 
 
 
Gil
Guest
Posts: n/a
 
      12-19-2011
On Dec 16, 2:59*am, "Alf P. Steinbach" <alf.p.steinbach
(E-Mail Removed)> wrote:
> <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}
>
> </code>
>
> Example errors with Visual C++ 10.0 and MinGW g++ 4.4.1:
>
> <example>
> [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::uni
> que_ptr<_Ty>'
> * * * * *with
> * * * * *[
> * * * * * * *_Ty=const T []
> * * * * *]
> * * * * *C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\INCLUDE\memory(2509) : see declaration of 'std::unique_pt
> r<_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 mai
> n()':
> c:\program files
> (x86)\codeblocks\mingw\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/unique_ptr.h:379:
> error: deleted f
> unction '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]
> *> _
> </example>
>
> 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?
>


no

> If the code is formally invalid, does the standard's wording reflect the
> intent


yes

> (i.e., is a DR appropriate)?


no

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


yes

>
> Cheers,
>
> - Alf


read [unique.ptr.runtime.ctor].

hth,
Gil
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      12-19-2011
On 19.12.2011 22:11, Gil wrote:
> On Dec 16, 2:59 am, "Alf P. Steinbach"<alf.p.steinbach
> (E-Mail Removed)> wrote:
>> <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}
>>
>> </code>
>>
>> Example errors with Visual C++ 10.0 and MinGW g++ 4.4.1:
>>
>> <example>
>> [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::uni
>> que_ptr<_Ty>'
>> with
>> [
>> _Ty=const T []
>> ]
>> C:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\INCLUDE\memory(2509) : see declaration of 'std::unique_pt
>> r<_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 mai
>> n()':
>> c:\program files
>> (x86)\codeblocks\mingw\bin\../lib/gcc/mingw32/4.4.1/include/c++/bits/unique_ptr.h:379:
>> error: deleted f
>> unction '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]
>> > _

>> </example>
>>
>> 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?
>>

>
> no
>
>> If the code is formally invalid, does the standard's wording reflect the
>> intent

>
> yes
>
>> (i.e., is a DR appropriate)?

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

>
> yes
>
> read [unique.ptr.runtime.ctor].


Thanks for you comments, Gil.

As it turned out, the code is invalid, but the standard's wording does
not seem to have reflected the authors' intent.

A DR has been filed, LWG 2118, <url:
http://cplusplus.github.com/LWG/lwg-active.html#2118>. However a number
of related issues (reset, deleter) popped up. Maybe a new DR will be
opened for the combined total issue, I don't know.


Cheers,

- Alf
 
Reply With Quote
 
SG
Guest
Posts: n/a
 
      12-20-2011
On 19 Dez., 22:59, Alf P. Steinbach wrote:
>
> A DR has been filed, LWG 2118, <url:http://cplusplus.github.com/LWG/lwg-active.html#2118>.
> However a number of related issues (reset, deleter) popped up. Maybe a new DR will be
> opened for the combined total issue, I don't know.


FWIW, you have my support. I agree that the current wording is a bit
over-eager with respect to disabling pointer type conversions. The
intention is probably to avoid pointer arithmetic bugs in inheritance
hierarchies.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
const vector<const MyType> Vs const vector<MyType> magnus.moraberg@gmail.com C++ 2 02-09-2009 10:45 PM
is const necessary in eg int compar(const void *, const void *) lovecreatesbeauty@gmail.c0m C Programming 26 11-10-2008 09:47 PM
const correctness - should C++ prefer const member over non-const? fungus C++ 13 10-31-2008 05:33 AM
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
Casting int'** to 'const int * const * const' dosn't work, why? Jonas.Holmsten@gmail.com C Programming 11 07-01-2007 06:16 PM



Advertisments