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
> 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