Relocation (= move+destroy)

[Marc Glisse]

On Tue, 23 Oct 2018, Jonathan Wakely wrote:

>>>> +  template<typename _Tp, typename _Up, typename _Allocator>
>>>> +    inline void
>>>> +    __relocate_a(_Tp* __dest, _Up* __orig, _Allocator& __alloc)
>>> 
>>> I find it a little surprising that this overload for single objects
>>> using the memmove argument ordering (dest, source) but the range overload
>>> below uses the STL ordering (source_begin, source_end, dest).
>>> 
>>> But I wouldn't be surprised if we're already doing that somewhere that
>>> I've forgotten about.
>>> 
>>> WOuld it make sense to either rename this overload, or to use
>>> consistent argument ordering for the two __relocate_a overloads?
>> 
>> The functions were not meant as overloads, it just happened that I arrived 
>> at the same name for both, but it would make perfect sense to give them 
>> different names. I started from __relocate(dest, source) for one element, 
>> and later added an allocator to it. The other one corresponds to 
>> __uninitialized_move_a, and naming it __uninitialized_relocate_a would be 
>> silly since "uninitialized" is included in the definition of relocate.
>
> Yes, my first thought was to add "uninitialized" and I rejected it for
> that same reason.
>
>> I think I'd rather rename than change the order. Do you have suggestions? 
>> __relocate_range_a?
>
> I was thinking the single object one could be __relocate_1_a with the
> _1 being like copy_n, fill_n etc. but that's going to be confusing
> with __relocate_a_1 instead!
>
> It seems unfortunate to have to put "range" in the name when no other
> algos that work on ranges bother to say that in the name.
>
> Maybe the single object one could be __relocate_single_a? Or
> __do_relocate_a? __relocate_obj_a? None of them really makes me happy.

I went with __relocate_object_a, but that's easy to change.

We may want to specialize / overload __relocate_object_a for some specific 
types in the future, although we would more likely have 
__relocate_object_a call __relocate_object (no allocator) when it receives 
the default allocator, and specialize that one. And this should anyway be 
less common that specializing __is_trivially_relocatable.

I just realized that __reallocate_a and construct don't take the allocator 
argument in the same position... I can switch if it helps.

Regtested on gcc112.

2018-10-25  Marc Glisse  <marc.glisse@inria.fr>

 	PR libstdc++/87106
 	* include/bits/alloc_traits.h (_S_construct, _S_destroy, construct,
 	destroy): Add noexcept specification.
 	* include/bits/allocator.h (construct, destroy): Likewise.
 	* include/ext/alloc_traits.h (construct, destroy): Likewise.
 	* include/ext/malloc_allocator.h (construct, destroy): Likewise.
 	* include/ext/new_allocator.h (construct, destroy): Likewise.
 	* include/bits/stl_uninitialized.h (__relocate_object_a, __relocate_a,
 	__relocate_a_1): New functions.
 	(__is_trivially_relocatable): New class.
 	* include/bits/stl_vector.h (__use_relocate): New static member.
 	* include/bits/vector.tcc (reserve, _M_realloc_insert,
 	_M_default_append): Use __relocate_a.
 	(reserve, _M_assign_aux, _M_realloc_insert, _M_fill_insert,
 	_M_default_append, _M_range_insert): Move _GLIBCXX_ASAN_ANNOTATE_REINIT
 	after _Destroy.
 	* testsuite/23_containers/vector/modifiers/push_back/49836.cc:
 	Replace CopyConsOnlyType with DelAnyAssign.


-- 
Marc Glisse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reloc.patch
Type: text/x-diff
Size: 24970 bytes
Desc: 
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20181025/3e1717d2/attachment.bin>