This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Possible bug in shared_ptr(unique_ptr) constructor?
- From: Daniel Krügler <daniel dot kruegler at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Brad Spencer <spencer at starscale dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 7 Oct 2013 19:25:31 +0200
- Subject: Re: Possible bug in shared_ptr(unique_ptr) constructor?
- Authentication-results: sourceware.org; auth=none
- References: <20131007123915 dot GA11628 at starscale dot com> <CAH6eHdQFFO8EXFNavumHguHs5-wtDaDtJ=0kvY7E_WNHqydTrw at mail dot gmail dot com> <CAH6eHdRb-4nL-z7LZdLBwyjJHYY74NTCXDYJhcBaHeZLXzvC0g at mail dot gmail dot com> <CAGNvRgDREhSacawseYzF04HZ3Z5uSYmw8-TDyL82sB4ZrGiO7w at mail dot gmail dot com> <CAH6eHdRa-vsc7AcWCZeZk2zmNKFyO+dHbuU=1xmAxoDZczpx5g at mail dot gmail dot com>
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