Hi everyone!

Thanks for the interesting and useful feedback on these two papers. The
authors
will take everything under consideration and (in both cases, for different
reasons
and through different approaches) will use it to carve a new and improved
version,
though not for the Feb. mailing since it's very close.

If SG14 wants to discuss them further tomorrow and provide additional
feedback,
that's fine and it will be taken into account, but there's already good
material
to work from so if the agenda's full there's no need to rush this.

Cheers!

Le mar. 13 févr. 2024 à 11:21, Jens Maurer via SG14 <sg14_at_[hidden]>
a écrit :

>
>
> 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
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>