Possible bug in shared_ptr(unique_ptr) constructor?

[Daniel Krügler]

2013/10/7 Jonathan Wakely <jwakely.gcc@gmail.com>:
> 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.

Thanks, this was the information I was missing (and I was too lazy to
check ;-)).

> 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 :-)

I tend to argue that this would violate in some way "the
specialization meets the standard library requirements".

> 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.)

I agree - Thanks for your explanation!

- Daniel