On 4/26/2023 3:57 AM, Öö Tiib wrote:
> On Wednesday, 26 April 2023 at 10:26:53 UTC+3, David Brown wrote:
>> On 26/04/2023 07:58, Öö Tiib wrote:
>>> On Tuesday, 25 April 2023 at 23:32:28 UTC+3, Chris M. Thomasson wrote:
>>>> On 4/25/2023 6:58 AM, Öö Tiib wrote:
>>>>> On Tuesday, 25 April 2023 at 16:25:04 UTC+3, Tony Oliver wrote:
>>>>>> On Monday, 24 April 2023 at 14:55:06 UTC+1, Öö Tiib wrote:
>>>>>>> On Monday, 24 April 2023 at 14:07:28 UTC+3, Bonita Montero wrote:
>>>>>>>> Am 24.04.2023 um 12:29 schrieb Öö Tiib:
>>>>>>>>
>>>>>>>>> Programmers tend to have real features to implement and problems
>>>>>>>>> to solve. You failed to tell why they should waste time to doing
>>>>>>>>> beta testing for gradually emerging half-baked C++23 features
>>>>>>>>> instead.
>>>>>>>> It's not about beta-testing.
>>>>>>>> It's about keeping up with what's coming.
>>>>>>>
>>>>>>> I briefly skimmed over that std::expected ... it had no much benefits
>>>>>>> compared to std::variant<Success, Failure>.
>>>>>>
>>>>>> Too briefly, it seems. That analogy with std::variant is way off the mark.
>>>>>>
>>>>> Yes, usage of variant is easier as it has visitors. With that class one got
>>>>> to write if else chain ... that does not differ much from what Chris mocks
>>>>> in other thread.
>>>>
>>>> I was not really mocking the "style", just how some programmers do not
>>>> like it at all... Personally, I don't mind it. Each function has a
>>>> struct for input and a struct for output.
>>>>
>>> OK. I do not hate it but I feel it has same issue with returning std::optional
>>> or std::expected, there is additional copy (or hopefully move) made for
>>> composing such function arguments and return value and so it inhibits the
>>> effect (or works in the opposite direction) of NRVO. Especially on
>>> case of heavy-weight "success" objects passed the performance can
>>> drop after refactoring to it. And performance issue means that the
>>> style can not be used idiomatically/uniformly.
>>
>> In regard to performance issues, you might want to do some testing and
>> measuring.
>
> What is the ground of implication that I do not? You think those are my
> half-educated guesses? Nope. Those are actually reverted commits because
> of proven degradation of performance.
>
>> Small structures on modern processors can be passed and
>> returned in registers in many cases. The use of structs for parameters
>> and return values might limit the compiler's choice of registers and
>> force a bit more register-to-register moves, but these are often almost
>> free in modern processors since they manipulate the register renaming
>> maps rather than actually moving data around.
>>
> Note that I mentioned heavy-weight above.
>
>> Whether or not you like Chris' style or not is a different matter, of
>> course - I'm just saying that it will not necessarily have the
>> performance implications you suggest.
>>
> It sometimes has and sometimes does not have. I'm repeating for
> to point arrive more surely, it cannot be used idiomatically/uniformly.

I have worked on systems that had large input structures. They would be
passed into a function as a const reference. The function would do its
thing, and return a structure that had say a glm::vec3 and a status.
Then I have worked on other systems that had the input and output
structs in the parameters and would return a status in the form of an
unsigned long that had many error conditions packed into said unsigned
value. Kind of like:
____________________
unsigned long
foo(
foo_input const& input,
foo_output& output
) {
// whatever
return 0; // or some status value
} ____________________

Output can be written to, input is constant, and it would return a
status unsigned long to the caller.