C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Return Value Optimisation whenever you need it (guaranteed elision)

From: Magnus Fromreide <magfr_at_[hidden]>
Date: Sat, 22 Jul 2023 02:56:05 +0200
On Sun, Jul 16, 2023 at 09:22:29PM +0100, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Sun, Jul 16, 2023 at 5:09 PM Arthur O'Dwyer wrote:
> >
> > The problem with this — and with the inline-assembly stuff — is that it's not portable C++
>
>
> I've had an epiphany.
>
> I was about to start writing assembler for Microsoft x64, cdecl,
> stdcall, aarch64, arm32 . . . and I had started by reading through
> Microsoft's description of its 64-Bit x86 calling convention, when I
> noticed something.
>
> All of these calling conventions have something in common. If the
> return type is a class by value, then the caller function passes the
> address of allocated memory to the callee as though it were the first
> argument to the callee (and all of the other arguments get moved down
> one space). So let's say we start off with a function whose signature
> is:
>
> std::mutex Func(void);
>
> Well, really this gets invoked by the compiler as though it were:
>
> void Func(std::mutex*);
>
> And so if you want to write a function that returns a locked mutex by
> value, all you need to do is:
>
> void Func_detail(std::mutex *const p)
> {
> ::new(p) std::mutex();
> p->lock();
> }

All of ths sounds a whole lot like the old "Named Return Values" extension
that used to be in GCC.

http://csci.viu.ca/~pwalsh/teaching/261/261/hc11/doc/gcc_5.html#SEC107

You might have added some extra guarantees to it but I am not even sure of
that, one problem with old GCC extensions was that they sometimes were a
bit underspecified.

/MF

Received on 2023-07-22 00:56:09