C++ Logo


Advanced search

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

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Mon, 30 May 2022 14:07:36 -0400
On Mon, May 30, 2022 at 1:56 PM Edward Catmur <ecatmur_at_[hidden]>

> On Mon, 30 May 2022 at 11:25, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>> I strongly discourage making any Memmi/Derrida–style subtle distinctions
>> between the words "immobile" and "immovable."
>> I suggest phrases like "types that have an `operator reloc` but no move
>> constructor" (describing the physical situation) or "types that are
>> conceptually movable but lack any moved-from state" (describing the
>> conceptual situation).
> Well, yes, but that's a bit of a mouthful, so people will come up with a
> more concise terminology, or at best an initialism.

Maybe, but you don't have to help them. ;)


> template<class T> requires std::is_noexcept_relocatable_v<T>
> void swap(T& lhs, T& rhs) {
> T temp = relocate_at(&lhs);
> new (&lhs) T(relocate_at(&rhs));
> new (&rhs) T(relocate_at(&temp));
> }
> (relocate_at is the magic library function that (destroys and) relocates
> its argument into a returned prvalue.)

Terminology nit: `relocate_at` takes a pointer parameter `dest`, just like
`construct_at` and `destroy_at`.
*`relocate` with no suffix* is the magic library function that relocates
into a returned prvalue.

The advantage of a syntax is that you can express trivial relocation simply
>>> by defaulting it, and it Does The Right Thing if any member becomes
>>> non-trivial.
>> Pedantic terminology nit: Just like with any other special member,
>> `=default` on your `operator reloc` wouldn't mean it was *trivial*; it
>> would just mean it was *defaulted*, i.e., *memberwise*.
>> struct A { std::string s; operator reloc(A&&) = default; }; //
>> memberwise and trivial
>> struct B { std::any a; operator reloc(B&&) = default; }; // memberwise
>> and non-trivial
> Absolutely, yes; and that's an advantage, since it means that a memberwise
> (defaulted) relocation operation is trivial precisely when each subobject
> is trivially relocatable; you won't end up making mistakes when changing
> data members or if another programmer changes the semantics of a type that
> you use.
> Aside: is std::string necessarily trivially relocatable? I seem to
> remember in the old days some SSO strings that used self-reference, but
> maybe no library implementor has gone for that strategy.

I already linked to that blog post. :)
TLDR: std::string is trivially relocatable on MSVC and libc++ (in non-debug
mode); but not on libstdc++ because pointer-to-self.


Received on 2022-05-30 18:07:48