On 25/02/20 16:01 +0200, Ville Voutilainen wrote:
On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely wrote:
I think what I'd really like to do is get rid of __memmove entirely.
We already have code that does the explicit assignment in a loop, for
the cases where we can't use __builtin_memmove becaus
On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely wrote:
> I think what I'd really like to do is get rid of __memmove entirely.
> We already have code that does the explicit assignment in a loop, for
> the cases where we can't use __builtin_memmove because the type is not
> trivially copyable.
>
> We
On 25/02/20 12:40 +, Jonathan Wakely wrote:
The std::move and std::move_backward algorithms dispatch to the
std::__memmove helper when appropriate. That function uses a
pointer-to-const for the source values, preventing them from being
moved. The two callers of that function have the same pro
On 25/02/20 12:40 +, Jonathan Wakely wrote:
The std::move and std::move_backward algorithms dispatch to the
std::__memmove helper when appropriate. That function uses a
pointer-to-const for the source values, preventing them from being
moved. The two callers of that function have the same pro
The std::move and std::move_backward algorithms dispatch to the
std::__memmove helper when appropriate. That function uses a
pointer-to-const for the source values, preventing them from being
moved. The two callers of that function have the same problem.
Rather than altering __memmove and its call
