C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Wed, 17 Jul 2024 20:55:58 +0100
On 16/07/2024 09:23, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Mon, Jul 15, 2024 at 4:33 PM Jason McKesson wrote:
>>
>> This is why understanding the philosophy behind something like
>> guaranteed NRVO is so important. It exposes the issues of going from
>> lvalue to prvalue back to lvalue and the myriad of complexities around
>> it. You can't just gloss over it; it must be central to any such
>> proposal.
>
>
> std::factory is now P3357, available here:
>
> https://isocpp.org/files/papers/P3357R0.html
>
> In the future we were thinking we would rename 'factory' to
> 'construct_modify', and rename 'after_factory' to 'invoke_modify'.

In P2025 there is guaranteed copy elision for `w` in the following:

Widget foo(int i) {
   {
     auto w = Widget(i);
     if (w.some_observer()) {
       return w;
     }
   }
   return Widget(0);
}

The way it works in practice is that `w` gets constructed on the return
slot, then depending on the result from the observer it is either
returned from there, or it's destroyed and a new object (Widget(0)) is
created on the same return slot before returning from the function. The
explicit scope for `w` is important here.

Last time I tried I do get NRVO here for clang, but not for gcc.

How do I achieve the same thing with P3357, especially with taking care
of exception safety?

Cheers,
Lénárd

Received on 2024-07-17 19:56:01