Possible bug in shared_ptr(unique_ptr) constructor?

[Jonathan Wakely]

On 7 October 2013 18:01, Daniel Krügler <daniel.kruegler@gmail.com> wrote:
> 2013/10/7 Jonathan Wakely <jwakely.gcc@gmail.com>:
>> And here's a suggested patch to fix it:
>>
>> +      template<typename _Sp, typename _Up>
>> +       static _Sp_counted_base<_Lp>*
>> +       _S_do_create_from_up(_Up&& __r)
>> +       {
>> +         using _Alloc = std::allocator<_Sp>;
>> +         using _ATr = std::allocator_traits<_Alloc>;
>> +         _Alloc __a;
>> +         auto __ptr = _ATr::allocate(__a, 1);
>> +         _ATr::construct(__a, __ptr, __r.get(), __r.get_deleter());
>> +         return __ptr;
>>         }
>
> Question: Is it impossible that the construction could throw an
> exception here or why is there no need to RAII-protect the
> intermediate __ptr value?

It's a good question.  All constructors of _Sp_counted_deleter are
noexcept, on the basis that the allocator's copy constructor and the
deleter's copy constructor must not throw according to
[util.smartptr.shared.const]/8.

If a user specializes std::allocator<_Sp_counted_deleter<...>> (or the
corresponding allocator_traits) and makes the construct() function
throw then they get to keep the pieces :-)

So I don't think we need to protect against exceptions here (although
I'll think about it more carefully before I commit the patch.)