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: Peter Dimov (lists_at_[hidden])
Date: 2014-09-03 05:08:34

Ion Gaztañaga wrote:
> Semantics might be a bit more clear for default_delete, as it calls 
> delete. std::is_polymorphic might not be very accurate, maybe 
> std::has_virtual_destructor.

has_virtual_destructor is the correct one. It's a later addition and the 
implementation on which I prototyped probably didn't have it.

> A user-defined deleter could be a no-op or an operation that can properly 
> recycle (link it in a intrusive list, etc.) the object even if it has no 
> virtual destructor, just because it doesn't call the destructor.

In principle, we should leave everything to the deleter. The problem is that 
in practice things like the following often occur:

struct X
{
};

struct Y: X
{
    std::string s_;
};

struct D
{
    template<class T> void operator()( T* p ) const { delete p; }
};

int main()
{
    unique_ptr<Y, D> p1( new Y );
    unique_ptr<X, D> p2( p1 ); // legal?
}

The array case is similar:

struct E
{
    template<class T> void operator()( T* p ) const { delete[] p; }
};

int main()
{
    unique_ptr<Y[], E> p1( new Y[3] );
    unique_ptr<X[], E> p2( p1 ); // legal?
}

although here we do have grounds on which to reject - we know that 
operator[] will not work.

I agree that the deleter may in principle not delete, and therefore the 
non-array conversion case may be safe. On the other hand, the obvious 
shared_ptr example, the one with the null deleter, doesn't translate, and 
I'm not sure I can come up with another (for which conversions are 
desirable).