in reply to Re: Evaluation Order again.
in thread Evaluation Order again.

As usual, C++ keeps introducing features that are supposed to fix previous C++ features.

To be fair, C++ inherited the undefined execution order from C (from bcpl from B from ... ). It was the done thing to leave such implementation details "to the implementation"; and expect programmers to perceive all the situations where they might be bitten by that seemingly innocuous statement.

One of the driving forces behind this is one of the other goals of C++17; that of introducing implicit parallelisations. Another suggested benefit roundly poo hoo'd in that old thread.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^3: Evaluation Order again.
by Anonymous Monk on May 28, 2016 at 01:31 UTC
    Don't take me wrong, I'm not saying that the order of evaluation of lists in Perl has a good reason to be undefined. I don't know if there such a reason; I suspect there isn't.
    To be fair, C++ inherited the undefined execution order from C (from bcpl from B from ... ).
    And inheriting various crap from C was also very much a feature (that needed - still needs - subsequent fixing)!
[reply]

In Section Meditations