[C++][cppconf 2018] "Trivially Relocatable" Arthur O'Dwyer

Definition:
iff a move constructor and a destructor are non-trivial in pair,
the result is tantamount to 'memcpy', thus defined by Arthur as 'relocatable'.

e.g std::shared_ptr

Thus, in compiler, can't we just do a 'memcpy' instead of following
the language syntax doing a move construct + destruct?
Yes, we can!


Reference:
https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-relocatable/
https://www.youtube.com/watch?v=8u5Qi4FgTP8

assembly: call vs. callq
https://stackoverflow.com/a/46753525
quote:
It's just 'call'. Use Intel-syntax disassembly if you want to be able to look up instructions in the Intel/AMD manuals.

The q operand-size suffix does technically apply (it pushes a 64-bit return address and treats RIP as a 64-bit register), but there's no way to override it with instruction prefixes.
i.e. calll and callw aren't encodeable in 64-bit mode, so it's just annoying that some AT&T syntax tools show it as callq instead of call. This of course applies to retq as well.


Is this new?
nope :-)
In Lippman's Inside the C++ Object Model mentioned that inside the copy constructor
we could use system call memcpy to speed up the bit-wise copy; however, there's a gotcha, which is  object slice, which could accidentally copy the derived object's v-ptr.
In Arthur's proposal, we modify compiler(not run-time), implement the memcpy directly when
the type has Rule Of Zero trait.
C++ core quideline: C.20: If you can avoid defining default operations, do
C++ core guideline: C.67: A polymorphic class should suppress copying