Relocation (= move+destroy)

[Marc Glisse]

On Tue, 23 Oct 2018, Jonathan Wakely wrote:

> CCing gcc-patches

It seems to have disappeared somehow during the discussion, sorry.

> The tricky stuff in <bits/stl_vector.h> all looks right, I only have
> some comments on the __relocate_a functions ...
>
>
>> Index: libstdc++-v3/include/bits/stl_uninitialized.h
>> ===================================================================
>> --- libstdc++-v3/include/bits/stl_uninitialized.h	(revision 265289)
>> +++ libstdc++-v3/include/bits/stl_uninitialized.h	(working copy)
>> @@ -872,14 +872,75 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>     uninitialized_move_n(_InputIterator __first, _Size __count,
>> 			 _ForwardIterator __result)
>>     {
>>       auto __res = std::__uninitialized_copy_n_pair
>> 	(_GLIBCXX_MAKE_MOVE_ITERATOR(__first),
>> 	 __count, __result);
>>       return {__res.first.base(), __res.second};
>>     }
>> #endif
>> 
>> +#if __cplusplus >= 201402L
>
> What depends on C++14 here? Just enable_if_t? Because we have
> __enable_if_t for use in C++11.
>
> Both GCC and Clang will allow constexpr-if and static_assert with no
> message in C++11.

Probably it can be enabled in C++11 if you think that matters. I'll admit 
that I personally don't care at all about C++11, and the main motivation 
would be to enable a cleanup if we stop supporting C++03 (I am not very 
optimistic).

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

I think I'd rather rename than change the order. Do you have suggestions? 
__relocate_range_a?

>> + 
>> noexcept(noexcept(__gnu_cxx::__alloc_traits<_Allocator>::construct(__alloc,
>
> Since this is C++14 (or maybe C++11) you could just use
> std::allocator_traits directly. __gnu_cxx::__alloc_traits is to
> provide equivalent functionality in C++98 code.

Thanks, I was wondering what it was for.

>> +			 __dest, std::move(*__orig)))
>> +	     && noexcept(__gnu_cxx::__alloc_traits<_Allocator>::destroy(
>> +			    __alloc, std::__addressof(*__orig))))
>> +    {
>> +      typedef __gnu_cxx::__alloc_traits<_Allocator> __traits;
>> +      __traits::construct(__alloc, __dest, std::move(*__orig));
>> +      __traits::destroy(__alloc, std::__addressof(*__orig));
>> +    }
>> +
>> +  template<typename _Tp>
>> +    struct __is_trivially_relocatable
>> +    : is_trivial<_Tp> { };
>
> It might be worth adding a comment that this type might be specialized
> in future, so that I don't forget and simplify it to an alias template
> later :-)

Ok.

-- 
Marc Glisse