StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>As long as we are talking about built-in operators: no, you are not changing the order of evaluation by using the <code>()</code>. You have no control over the order of evaluation. In fact, there's no "order of evaluation" here at all.</p> <p>The compiler is allowed to evaluate this expression in any way it desires, as long as the result is correct. It is not even required to use addition and multiplication operations to evaluate these expressions. The addition and multiplication only exist in the text of your program. The compiler is free to totally and completely ignore these specific operations. On some hardware platform, such expressions might be evaluated by a single atomic machine operation. For this reason, the notion of "order of evaluation" does not make any sense here. There's nothing there that you can apply the concept of "order" to.</p> <p>The only thing you are changing by using <code>()</code> is the mathematical meaning of the expression. Let's say <code>a</code>, <code>b</code> and <code>c</code> are all <code>2</code>. The <code>a + b * c</code> must evaluate to <code>6</code>, while <code>(a + b) * c</code> must evaluate to to <code>8</code>. That's it. This is the only thing that is guaranteed to you: that the results will be correct. How these results are obtained is totally unknown. The compiler might use absolutely anything, any method and any "order of evaluation" as long as the results are correct. </p> <p>For another example, if you have two such expressions in your program following each other</p> <pre><code>int x = c + a * b; int y = (c + a) * b; </code></pre> <p>the compiler is free to evaluate them as</p> <pre><code>int x = c + a * b; int y = c * b + x - c; </code></pre> <p>which will also produce the correct result (assuming no overflow-related problems). In which case the actual evaluation schedule will not even remotely look like something that you wrote in your source code.</p> <p>To put it short, to assume that the actual evaluation will have any significant resemblance to what you wrote in the source code of your program is naive at best. Despite popular belief, built-in operators are not generally translated in their machine "counterparts".</p> <p>The above applies to built-in operators, again. Once we start dealing with overloaded operators, things change drastically. Overloaded operators are indeed evaluated in full accordance with the semantic structure of the expression. There's some freedom there even with overloaded operators, but it is not as unrestricted as in case of built-in operators.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload