Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town

Subject: Re: [boost] [move][unique_ptr] c++14 unique_ptr comes to town
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-09-02 10:55:58

El 26/08/2014 18:54, Peter Dimov wrote:
> Mine is "more complete" in that it
> supports unique_ptr<T[N]> with proper shared_ptr-style conversions and
> is "better" in that it does all that with a single template, without
> triplication.

Hi Peter,

I've committed changeds to boost::movelib::unique_ptr now supports 
unique_ptr<T[N]>, adding the operator[] check mentioned in shared_ptr 
documentation. I have some doubts with these conversions. Currently I've 
implemented the conversions:

1) unique_ptr<T[]> -> unique_ptr<U[]>
2) unique_ptr<T[N]> -> unique_ptr<U[N]>
3) unique_ptr<T[N]> -> unique_ptr<U[]>

if remove_cv_t<T[]> == remove_cv_t<U[]>, pointers are convertible and 
deleters are convertible (and this is the key point).

Although not provided by the language (T(*)[N] is not convertible to 
U(*)[]), the third conversion is safe with the default deleter. A 
problem might occure if a user-provided deleter<T[N]> is be convertible 
to deleter<U[]> but it does not properly handle unknown-length arrays. 
The conversion will be unsafe. Deleter writers should be warned about 
this conversion.

On the other hand, with the default_deleter it could be safe to convert 
(maybe if N >= M):

4) unique_ptr<T[N]> -> unique_ptr<U[M]>

that is, we can safely create a slice of the array. I don't know if this 
conversion has any value. I understand conversion 3 is useful to get 
some data erasure and avoid propagating size though all the code. Is 
interesting to allow such conversion?

Best,

Ion