https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
Re-reading P1144R0 (those are not necessarily comments on the paper, just what
comes to mind for gcc):
1) yes, an automatic detection mechanism would be nice, and an attribute makes
sense.
2) the conditionally trivial stuff is not very convenient, it seems to involve
a lot of code duplication. People regularly suggest attributes of the form
[[trivially_relocatable(condition)]] which might reduce the noise but are
harder to specify.
3) there are indeed many places outside of vector that can benefit from
relocation. The compromises may not be the same though. For my use in vectors,
relocation was never worse, it performed the same moves and destructions as the
original. In other places, using relocation would replace a move-assignment
with a construction and a destruction, which could be worse, so we may want to
limit it to the trivially relocatable case.
4) I think it might be useful to be able to specify how to relocate an object
that is not trivially relocatable. Relocating a pair<A,B> where A is trivially
relocatable and B is not can still benefit from doing piecewise relocations so
it avoids A's super-costly move constructor. Ideally relocation would be a
constructor or something similarly magic and the compiler would auto-generate
it for aggregates, etc. But I am asking a bit much there...

By the way, thanks for keeping destructive moves alive :-)

Reply via email to