4 ms·
Because otherwise the evaluation order of the following construct is undefined, and you can get different results if you compile your code with different compil
by eklitzke 4y ago
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.
- addaon 4y agoBut 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...
- Dylan16807 4y ago> 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.