On Mon, 2 May 2022, 14:54 Edward Catmur, <ecatmur_at_[hidden]> wrote:


I thought of something similar:
struct T {
    operator reloc(); // return a new instance of T, like a constructor
would do
    // or as a static variant with signature:
    operator reloc(T&& self);
};

But I found it very inconvenient to write the function body:

struct T : public B {
    operator reloc() {
        // how to construct the B part of T into the new T using B's reloc?
        // how to initialise the data-members of T using the reloc
    }
}

This can hardly reuse the constructor syntax (with base class and
data-member initialisers). I couldn't find anything convincing in that
path, but I can still give it more thought.


Yes, this is a bit tricky (base classes in particular), though I have some
ideas about possible syntaxes. However, much of the time `= default` will
be sufficient, and in the remainder it may be acceptable to treat the
source object as an xvalue, on the proviso that it will be immediately
destructed. In other words I'm not convinced that this will be a problem in
practice; some examples of classes that would need a user-provided
relocation operation might help.


On the other hand, constructor style syntax is probably easier to
understand.

Since relocators really shouldn't be doing that much work (just adjusting
self references), wouldn't automatic base and memberwise relocation
followed by a fixup step (as a constructor function body) be sufficient?
The only place I can see this being problematic is in const data members,
but are these really going to be an issue in real world code? That is, they
do exist and are useful, but who actually has a const pointer data member
with value this?