This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Relocation (= move+destroy)
On 23/10/18 23:17 +0200, Marc Glisse wrote:
On Tue, 23 Oct 2018, Jonathan Wakely wrote:
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).
Me neither.
But even if enabling cleanup some day is unlikely, I think that for
this code the only change you'd need is to replace enable_if_t with
__enable_if_t and we get C++11 support for free, so we might as well
do it.
+ 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.
+ 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.
It's just so I could write code in containers that works the same for
C++11 allocators and C++98 allocators, always using __alloc_traits. In
C++98 it just forwards everything straight to the allocator, because
C++98 allocators are required to define all the members themselves.