Date: Tue, 13 Feb 2024 15:55:42 +0100
On 13/02/2024 01.42, Nicolas Fleury wrote:
> On Mon, Feb 12, 2024 at 5:50 PM Jens Maurer <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]>> wrote:
>
> I'm not seeing why the tiny bit of information about whether
> creating the return object had (e.g.) an extra move or not
> would be sufficiently interesting to the caller to announce
> that in the declaration. A lot of other performance-relevant
> details (such as whether additional copies are made in the
> implementation way before the return value is created,
> or whether an inefficient O(n^2) algorithm is used where
> O(n) would be possible) are not announced in the declaration,
> either.
>
>
> I actually want neither move nor copy.
Sure, but how do you prevent a stupid implementation that uses an O(n^2)
algorithm instead of an O(n) one, at the level of the declaration?
Answer: You don't with features of C++; you need processes outside of
the programming language proper. Same for the use or not of (N)RVO.
As a side note, NRVO is not mandatory, but optional, so if you want
guaranteed RVO, you should use RVO only.
> The goal is to allow SomeClass Foo(), and not only Foo(SomeClass&) on a huge production.
So, just do that, then. As a bonus, you avoid the default construction
of SomeClass in the caller.
> If we can't provide a way to write a signature in a way with as good performance on average,
The signature of a function has nothing to do with
whether NRVO (or plain RVO) will be applied or not.
This only depends on how the implementation is expressed.
(off-topic: The signature of a function excludes its return type,
see [defns.signature].)
> then we'll just stay Foo(SomeClass&), even if it's often more verbose. Of course, then the code inside the function is important that well, that's a given, but that's orthogonal to me.
>
> There will always be properties of a function that cannot
> be expressed in declarations alone, yet are important to
> some fraction of the callers.
>
>
> Yeah, but here we choose between 2 possible declarations. Maybe I'm just wrong and we should just keep using output arguments.
Maybe there's a confusion here: NRVO does not change the calling
convention of your function in any way.
Jens
> On Mon, Feb 12, 2024 at 5:50 PM Jens Maurer <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]>> wrote:
>
> I'm not seeing why the tiny bit of information about whether
> creating the return object had (e.g.) an extra move or not
> would be sufficiently interesting to the caller to announce
> that in the declaration. A lot of other performance-relevant
> details (such as whether additional copies are made in the
> implementation way before the return value is created,
> or whether an inefficient O(n^2) algorithm is used where
> O(n) would be possible) are not announced in the declaration,
> either.
>
>
> I actually want neither move nor copy.
Sure, but how do you prevent a stupid implementation that uses an O(n^2)
algorithm instead of an O(n) one, at the level of the declaration?
Answer: You don't with features of C++; you need processes outside of
the programming language proper. Same for the use or not of (N)RVO.
As a side note, NRVO is not mandatory, but optional, so if you want
guaranteed RVO, you should use RVO only.
> The goal is to allow SomeClass Foo(), and not only Foo(SomeClass&) on a huge production.
So, just do that, then. As a bonus, you avoid the default construction
of SomeClass in the caller.
> If we can't provide a way to write a signature in a way with as good performance on average,
The signature of a function has nothing to do with
whether NRVO (or plain RVO) will be applied or not.
This only depends on how the implementation is expressed.
(off-topic: The signature of a function excludes its return type,
see [defns.signature].)
> then we'll just stay Foo(SomeClass&), even if it's often more verbose. Of course, then the code inside the function is important that well, that's a given, but that's orthogonal to me.
>
> There will always be properties of a function that cannot
> be expressed in declarations alone, yet are important to
> some fraction of the callers.
>
>
> Yeah, but here we choose between 2 possible declarations. Maybe I'm just wrong and we should just keep using output arguments.
Maybe there's a confusion here: NRVO does not change the calling
convention of your function in any way.
Jens
Received on 2024-02-13 14:55:53