https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|ville.voutilainen at gmail dot com |redi at gcc dot gnu.org
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Barry Revzin from comment #8)
> Whereas the copy_b case could also use memmove.
I'd been working on the assumption that it can't, because for types that aren't
trivially default constructible we need a constructor to begin the lifetime.
But the rules for implicit-lifetime class types only require at least one
trivial constructor and a trivial destructor, so a trivial copy constructor is
enough. And memcpy/memmove implicitly create objects in the destination
storage.
I don't think that was really explicit before the implicit-lifetime rules in
C++20. The example in C++17 [basic.types] p3 implies that the destination
doesn't need to be an initialized object, but nothing said that normatively.
Quite the opposite: C++17 [basic.life] seems clear that initialisation must be
done for types with non-vacuous initialization (such as Barry's type B), and
nothing in C++17 said that memcpy/memmove do any initialization. C++20 is clear
though.
So:
- If the input and output type are the same size and both are trivially
constructible, we can use memcpy. We should call memcpy directly from
std::uninitialized_copy rather than via std::copy, because std::copy doesn't
allow overlapping ranges, and has to use memmove instead.
- If the output type is trivially default constructible and is assignable from
the input type, we can use std::copy (but it's unclear whether that gives any
benefit if we can't turn it into memcpy/memmove).
- Otherwise, just use std::construct_at on each element.
I have a patch, but it's for stage 1 not GCC 12.
