C++17 creates a practical use of the backward array index operator

Re:C++17 creates a practical use of the backward array index... by eklitzke on Monday April 03, 2023 @06:33PM (#35432249)

Because otherwise the evaluation order of the following construct is undefined, and you can get different results if you compile your code with different compilers:

  foo()[bar()];

In nearly all cases it won't matter, but it can matter if foo() and bar() have some kind of shared state (or affect each other's return values, but seriously don't do that). In general it's better to have a defined evaluation order unless there's some compelling reason not to.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by addaon on Monday April 03, 2023 @09:45PM (#35433912)

But both C and C++ are comfortable with *(foo() + bar()) having undefined evaluation order, so foo()[bar()] potentially having order-dependent results is clearly not sufficient reason for this decision...

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by Dylan16807 on Monday April 03, 2023 @09:54PM (#35433961)

> In general it's better to have a defined evaluation order unless there's some compelling reason not to.

That is not the stance C++ has taken in the past, so the question of why they changed it is still unanswered.

[ Parent | on HN ]