| blob | 782490f8a9fa56d0b1bc47723b578970503b32a9 |
2 <!-- This collection of hypertext pages is Copyright 1995, 1996 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
5 <html>
6 <head>
13 </head>
14 <body>
18 Precedence determines how an expression is parsed,
19 and it has an influence on the order in which parts of it are
20 evaluated,
21 but the influence isn't as strong as you'd think.
22 Precedence says that in the expression
24 </pre>the multiplication happens
25 before the addition.
26 But if we have several function calls,
27 such as
28 <pre> f() + g() * h()
29 </pre>we have no idea which function will be called first;
31 though its value won't be needed until last.
32 If we were to write an abomination like
34 a[i++] + a[i++] * a[i++]
36 increments would happen in,
37 and in fact the compiler wouldn't have any idea either.
39 higher precedence than addition, and since multiplication
41 happen first, then the third, then the first.
43 which side of a single binary operator gets evaluated first;
44 associativity says which of several adjacent same-precedence
45 operators happens first.)
46 </p><p>In general,
47 you should be wary of ever trying to
48 second-guess the relative order
49 in which the various parts of an expression will be evaluated,
50 with two exceptions:
51 <OL><li>You can obviously assume that precedence will dictate
52 the order in
53 which binary operators
54 are applied.
55 This typically says more than just what order things happens in,
57 (In other words,
59 says more than that the multiplication ``happens first''
63 are evaluated left-to-right,
64 and that the right-hand side is not evaluated at all
65 if the left-hand side determines the outcome.
66 </OL></p><p>To look at one more example,
67 it might seem that the code
69 printf("%d\n", i++ * i++);
73 not that it happens immediately,
74 so this code could print 49
75 (if it chose to perform the multiplication first,
76 and both increments later).
77 And,
78 it turns out that ambiguous expressions like this are such a
79 bad idea that the ANSI C Standard does not require compilers to
80 do anything reasonable with them at all,
81 such that
82 the above code
83 might end up
85 your computer.
86 </p><p>Finally,
87 note that parentheses don't dictate overall evaluation
88 order any more than precedence does.
89 Parentheses override precedence
90 and say which operands go with which operators,
91 and they therefore affect the overall meaning of an expression,
92 but they don't
93 say anything about the order of subexpressions or side effects.
94 We could not ``fix''
95 the evaluation order of
96 any of the
97 expressions we've been discussing
98 by adding parentheses.
99 If we wrote
100 <pre> f() + (g() * h())
101 </pre>we still wouldn't know whether
103 would be called first.
104 (The parentheses would force the multiplication to happen before the addition,
105 but precedence already would have forced that, anyway.)
106 If we wrote
107 <pre> (i++) * (i++)
108 </pre>the parentheses wouldn't force the increments to happen before
109 the multiplication or in any well-defined order;
110 this parenthesized version would be just as undefined as
113 </p><p>Deep sentence:
114 <blockquote>Function calls,
115 nested assignment statements,
116 and increment and decrement operators cause
117 ``side effects''--some
118 variable is changed as a by-product of the evaluation of an expression.
119 </blockquote>(There's a slight inaccuracy in this sentence:
121 </p><p>It's these ``side effects'' that you want to keep in
122 mind when you're making sure that your programs are well-defined
123 and don't suffer any of the undefined behavior we've been
124 discussing.
125 (When we informally said that
126 complex expressions had several things going on ``at once,''
127 we were actually referring to expressions with multiple side effects.)
128 As a general rule,
129 you should make sure that each expression only has one side effect,
130 or if it has several,
133 </p><p>Deep sentence:
134 <blockquote>The moral is that writing code
135 that depends on order of evaluation
136 is a bad programming practice in any language.
137 Naturally,
138 it is necessary to know what things to avoid,
139 but if you don't know
141 they are done on various machines,
142 you won't be tempted to take advantage of a particular implementation.
144 <blockquote>...if you don't know
146 they are done on various machines,
147 that innocence may help to protect you.
148 </blockquote>I actually prefer the first edition wording.
149 Many textbooks encourage you to write small programs
150 to find out how your compiler
151 implements some of these ambiguous expressions,
152 but it's
153 just
154 one step from writing a small program to find out,
155 to writing a real program which makes use of what you've just learned.
156 And
158 that work only under one particular compiler,
159 that take advantage of the way that compiler
160 (but perhaps no other)
161 happens to implement the undefined expressions.
162 It's fine to be curious about what goes on ``under the hood,''
163 and many of you will be curious enough about what's going on
164 with these ``forbidden'' expressions that you'll want to
165 investigate them,
166 but please keep very firmly in mind that,
167 for real programs,
168 the very easiest way of dealing with ambiguous, undefined expressions
169 (which one compiler interprets one way
170 and another interprets another way
171 and a third crashes on)
172 is not to write them in the first place.
173 </p><hr>
174 <p>
175 Read sequentially:
180 </p>
181 <p>
185 </p>
186 </body>
187 </html>