On Mon, 30 May 2022 at 10:52, Maciej Cencora via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Ok, but how can a type that needs custom relocation still be
> efficiently relocatable?
> E.g. if you need a fixup for self-reference, then relocating won't
> ever be as efficient as memcpy.
>

Yes, this is acceptable; performance is only one benefit of the proposal.

With operator reloc you will be able to skip a moved-from state check
> inside destructor (and sometimes additional member), but that will
> matter only if such types are stored in containers (i.e. there are a
> lot of objects of this type).
>

It matters for the class author, who has to write all this extra logic and
state for no benefit. Code that is not written does not have bugs.


> Also in containers implementers can already do all kinds of
> shenanigans to mitigate the cost (e.g. skip destructor call for
> moved-from objects for types that they know it is safe to do).
>

And how do they know it is safe to do so? By nonstandardized attributes and
special-case lists? Standardizing relocation allows everyone to communicate
this property, between implementers, users, and third-party library vendors.

So the question comes down to this: is it really worth to introduce
> even more complexity in the SMF area, for unknown benefit?
> If you have a non-trivially relocatable type, then even the new SMF
> operator reloc won't get you the same performance as similar trivially
> relocatable type.
>

Yes; this adds complexity in the special-member-function area, but it will
allow removing complexity in user code.