On Wednesday, October 22, 2025, Thiago Macieira wrote:

>
>
> Or, we mark the ones that are allowed. That's the relocatability attribute.
>


I don't understand your reasoning here, T Dogg.

To say that an object is trivially relocatable means that you can memcpy it
to a different address, invoke its methods, and everything will work fine.

To say that an object is relocatable, but not trivially so, means that
there is an algorithm that can relocate the object safely (I think I wrote
a paper on this . . . let me check real quick . . . actually I didn't but I
went into something similar on Page 2 of this paper and then later in the
paper I present an algorithm for relocating an std::string):


 https://www.virjacode.com/papers/unaligned_latest.pdf

So I understand what relocation is . . . and I understand that some classes
will have their methods malfunction if an object is moved to a different
address.

But...
    but...
        but...

I don't see how you're linking relocatability to what's going on in this
thread.

Essentially in this thread, I'm talking about constructing a new object and
waiting until we're sure it has been fully constructed before invoking the
destructor of the old object. My sneaky strategy of swapping raw bytes
around will work fine so long as, during the construction and destruction,
no object of type T tries to access another object of type T. This is
pretty reasonable as less than 1% of classes access some sort of global
directory of objects or have some sort of linked list to other existent
objects.

I don't see how my byte-swapping strategy has anything to do with
relocatability. Let me use a class as an example:

    std::string

This class is not trivially relocatable because the short-string
optimisation maintains a pointer into the object. A special algorithm is
needed to relocate an std::string (which I show in my above linked PDF
paper near the last page). But even though an std::string is not trivially
relocatable, there's absolutely no harm in swapping its bytes around to do
a clever construct and destruct trick.

The question is: Is it possible that the 'emplace_or_retain' function could
cause malfunctions with some classes? My answer is Yes, it can, if the
class in its constructor or destructor accesses other objects of the same
class. But I really don't understand where relocatability comes into it. I
don't get it.