On 16/07/2023 17.39, Frederick Virchanza Gotham via Std-Proposals wrote:
> I reply to Jason and Arthur in series below.
[...]
I don't like having this as a magic library function with plenty of
callbacks. If this is worth having in the standard, let's make sure
the core language offers the relevant facility.
(Being able to manually cause the named return value optimization
might be helpful beyond returning locked mutexes.)
Hear, hear.
Here's a version without inline assembly but still using "unnatural intimacy with the (Itanium) ABI":
The problem with this — and with the inline-assembly stuff — is that it's not portable C++. In fact, my version is so unportable that GCC barfs at -O1: it sees that we're reinterpret_cast'ing a function pointer to the "wrong" function type and then calling through it, which is UB, so it eliminates everything after that point.
This is tantalizingly similar, but not really the same, as something I just re-raised on the SG14 mailing list:
[...] a pair of attributes to stick on a variable: [[no_construct]], to skip the constructor but still destroy the variable at end-of-scope as usual; and [[no_destroy]] to do the constructor but skip the destructor.
Clang and GCC both support [[no_destroy]], but only on static and thread-local storage.
Nobody supports [[no_construct]] yet.
But I know about these attributes because if we had them for stack variables then the vendor could implement P1144 `T std::relocate(T*)` without intimate knowledge of the calling convention:
template<class T>
T relocate(T *src) {
if constexpr (std::is_trivially_relocatable_v<T>) {
[[do_not_construct]] T dst;
std::relocate_at(src, &dst); // construct dst and destroy src, as if by memcpy
return dst; // but still get the benefit of NRVO here
} else {
T dst = T(std::move(*src));
std::destroy_at(src);
return dst; // get the benefit of NRVO here
}
}
Notice I'm saying "still get the benefit of NRVO," but of course we still get NRVO only for movable types (because immovable types like `mutex` can't be NRVO'ed in the first place). So maybe these problems are not close together but orthogonal. :) Still, they're both in the same area — and the same area is also currently being explored by the various "non-trivial relocation" papers in the Varna mailing.
Cheers,
Arthur