Hacker News new | past | comments | ask | show | jobs | submit login

I'm not a big fan of UB either, but keeping the order of argument evaluation indeterminate seems very sensible to me.

Imagine you have a function like f(int, double). If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!




If there's really a performance advantage to argument reordering then you can do it whenever there are less than two arguments that may have side effects. Safe instances would be:

* constants

* regular variables that aren't using the cast constructor for implicit conversion

* member functions marked const

* constexpr functions

You would only need to actually evaluate function calls that may change global state, or that perform in-place assignment (eg f(x += 1, x += 2)).

I will take the performance impact of doing something 'stupid' like calling f(a(), b()) instead of splitting the expression up into three lines any day over potentially introducing a security vulnerability that I don't even know about and that the compiler doesn't warn me about any day of the week.

Performance is not the be-all end-all of the world. We should not make critical applications insecure in order to get our apps to be 0.0001% faster.

> If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!

... I don't understand how moving from arbitrary argument evaluation ordering to fixed argument evaluation ordering can possibly turn any valid code existing today into bad code. Quite the opposite, it has the potential to fix a lot of code. Anything that relied on the arguments being evaluated backward (I don't even know of a compiler that does that ... yet) would have been technically broken per the previous language specs anyway. So I don't know what point you are trying to make here, sorry.


My scenario is:

* There's a function f(int, double), called in ~100 places, written by many different people.

* For some reason I decide to change it to f(double, int). Consistency, or preparing for some other refactoring, whatever.

* I have to track down ~100 occurrences of f and exchange arguments. Time-consuming but no big deal.

* If any code was dependent upon compiler silently evaluating the arguments in a particular way, then the code was broken, and reasonably competent coders don't write too much broken code. (Moreover, such a dependency is 99% likely to be broken by random changes in codes or compiler options, so chances are that I wouldn't encounter too many such bugs.)

In your world, it is just about impossible. If I want to go ahead, I could either change every occurrence into:

    int arg1 = ...;
    double arg2 = ...;
    f(arg2, arg1);
...or pore through every line calling f to see if it's safe.

C++ already has a reputation of being a difficult language to refactor, and your proposal will make it about impossible.


Ah, I understand what you're saying now. I guess we'll have to agree to disagree, then.

I am much more interested in predictability in my code than I am about reordering arguments in mature codebases.

Lots of languages guarantee expression ordering to follow precedence and associativity rules, and I've never heard anyone say that it was a problem to refactor their code as a result.

Whereas I am 100% certain that there are lots of codebases where this is a ticking timebomb with developers unintentionally relying on the order their compiler decides to evaluate expressions in. And it will blow up when, not if, the GCC devs find some micro-optimization and decide to reverse things on them. And that's not just a problem for them, it's a problem for everyone who relies on their code.


I've spent over three decades using languages that guarantee left-to-right evaluation order (Common Lisp and Java), and I have not found this to be a problem in practice.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: