Re: Possible bug in shared_ptr(unique_ptr) constructor?

[Daniel Krügler <daniel dot kruegler at gmail dot com>]

2013/10/8 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 7 October 2013 22:34, Brad Spencer wrote:
>>
>> BTW, I noticed that when it's created from unique_ptr, shared_ptr uses
>> _Sp_counted_deleter even in the cases where the deleter is the
>> std::default_delete<T>.  Since _M_del is just a normal member of
>> _Sp_counted_deleter (no empty base optimization, etc.), does this mean
>> that a shared_ptr made from a unique_ptr uses a slightly larger than
>> necessary count object?  Is it worth trying to use _Sp_counted_ptr in
>> that case?
>
> It would be a nice space optimization and I was about to start coding
> it up, but I remembered two points:
>
> 1) Users are allowed to specialize std::default_delete<T> if T depends
> on a user-defined type (e.g.
> default_delete<std::vector<SomeNonStdType>>) in which case it could do
> something sneaky like log to std::cout every time it is invoked, so we
> can't unconditionally remove any use of std::default_delete.
>
> 2) on the trunk (what will be GCC 4.9) both the allocator and the
> deleter use the empty base optimization, so constructing a
> shared_ptr<T> from a unique_ptr<T, default_delete<T>> should already
> be no larger than necessary.

While reflecting about the same thing I found a third reason: The
current specification of this moving transfer means that after the
construction the programmer can query the free get_deleter template
and can expect to get the owned deleter (irrespective of
user-specialization), that is including default_delete<int> for
example. This is different from querying shared_ptrs that do not *own*
the deleter.

- Daniel