> If you glance at the
constant's name, you don't need to go looking in a header file or on
'cppreference.com' to figure out what the number is.


Why would you ever need to know the number?



On Sun, Nov 2, 2025 at 17:27 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Oct 31, 2025 at 11:31 PM Jeremy Rifkin wrote:
> >
> > The reloc named constants you provided still have these magic numbers in
> the name which is a bit odd.
>
>
> Perhaps out of ordinary, but efficient. If you glance at the
> constant's name, you don't need to go looking in a header file or on
> 'cppreference.com' to figure out what the number is.
>
> I've done more work on my paper. I've added descriptions of the
> different categories (1 = memcpy, 2 = compiler builtin, and so on).
> Latest draft is here:
>
> https://www.virjacode.com/papers/relocatability.htm
>
> Furthermore I've pointed out a weakness in 'restart_lifetime', in that
> it's not future-proof, as follows:
>
> restart_lifetime is declared as follows:
>
> template<typename T>
> T *restart_lifetime(T *p) noexcept;
>
> This function is a no-op on all platforms except for arm64e. On
> arm64e, the object’s new address is enough information to correctly
> re-encrypt the vtable pointer. However in the future, there might be
> an architecture with a more complicated pointer authentication system,
> and the re-encrypting of the vtable pointer might also require the
> object’s old address. And so the declaration would need to change to:
>
> template<typename T>
> T *restart_lifetime(T *old, T *new) noexcept;
>
> This is why restart_lifetime shouldn't be exposed to the programmer,
> and all this stuff should be done inside std::relocate.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>