Boost logo

Boost :

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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at