On 13/02/2024 16.59, Nicolas Fleury wrote:
> On Tue, Feb 13, 2024 at 9:55 AM Jens Maurer <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]>> wrote:
>
> > 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.
>
>
> No, we won't today, since that would result in worse performance on average, or let's say overall. I think there's a misunderstanding of what a big video game production is, or at least the reality I'm trying to address. If we have 200 C++ programmers working on a game, we will choose the rules that are best for the game. If we allow people to return by copy things that should not be copied, we will end up with a lot of unwanted copies, as people make mistakes or have imperfect understanding of RVO. I know it depends on the function implementation only. I know you can follow simple rules in the implementation to have RVO done. Of course, we can say "well, your programmers just need to learn C++ better", but the reality is that I have to choose rules producing the best result overall, with the mix of junior and senior programmers. All our senior programmers conclude today to go with Foo(SomeClass&). I'm evaluating if we could do better.

So, you want a static analysis tool that tells your programmers when
a return-by-value function doesn't use (N)RVO? Sounds like a clang
patch to me.

> Imagine you have 500 C++ programmers, half of them juniors, and you have to decide between SomeClass Foo() and void Foo(SomeClass&) as a guideline. Your life depends on the one giving the best overall performance for 10 million lines of code. Which one do you choose? From my experience it's a no-brainer to go today with void Foo(SomeClass&), as all copies are explicit. If we like the elegance of SomeClass Foo(), what the guidelines could be to be as good as Foo(SomeClass&)? Remember, your life depends on it:) I tend to think we need [[some_name]] SomeClass Foo(), but could the attribute be only on return statements and calling lines? I would not bet my life that the overall result is as-good.

Sounds like you want a static analysis tool that supports your particular
coding style with appropriate warnings, not a feature in the standard.

> BTW, I mostly only care about LTO builds as well, so any optimization done with inlining is fine with me as well.

I don't understand how this statement helps with adding a feature in the standard;
those need to work with and without LTO all the same.

Jens