On 25/10/18 14:30 +0200, Marc Glisse wrote:
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.
I'm OK with that. If anybody thinks of a better name we can change it.
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.
No, leaving it at the end is consistent with __uninitialized_copy_a
et al, and it's closer in spirit to them.
OK for trunk, thanks!
