This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::vector allocator-extended move constructor
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 15 Nov 2013 12:34:26 +0000
- Subject: Re: std::vector allocator-extended move constructor
- Authentication-results: sourceware.org; auth=none
- References: <CAH6eHdRu84qSkX54PjTuoWAJoNdkfaWjQ9A0wzW2-C7vh0xehw at mail dot gmail dot com> <CAH6eHdToY4pswgEjwKm9oQ9hiu64DHdwg6v2VDEmL=KtRxmPGQ at mail dot gmail dot com>
On 15 November 2013 12:17, Jonathan Wakely wrote:
> On 15 November 2013 12:11, Jonathan Wakely wrote:
>> The good news is that if all instances of the allocator type compare
>> equal then the _Base will just move some pointers, so we can have a
>> conditional noexcept:
>> noexcept(_Alloc_traits::_S_always_equal())
>>
>> The bad news is that it's not currently exception-safe. I should have
>> used __uninitialized_copy_a there. If moving any element throws an
>> exception then we leak any already-moved elements.
>
> Correction, we don't leak, as __uninitialized_copy_a will destroy
> them, but we do modify the __rv object, so we don't have the strong
> guarantee. I'm not sure if that constructor is supposed to provide
> the strong guarantee or not.
Since it's an rvalue I don't think we need to preserve its contents
even if an exception is thrown, so I'm going to add the noexcept and
not change the call to __uninitialized_move_a.
One day I hope I'll be able to stop thinking about allocators ...