C++ Logo


Advanced search

Re: [std-proposals] Relocation in C++

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Mon, 30 May 2022 11:06:40 -0600
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.

Received on 2022-05-30 17:06:53