440,928 Members | 1,200 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,928 IT Pros & Developers. It's quick & easy.

# expression and evaluation order and precedence rules

 P: n/a hi, i am a bit confused on expression evaluation order in expressions involving unary increment.decrement operators along with binary operators. For example in the following expression x += i + j + k++; is the following the sequence of evaluations 1) as ++ has highest precedencce subexpression k++ gets evaluated 2) i + j is evaluated next and say the result is stored in a temporary location say temp 3) next temp + k++ gets evaluated and result stored in temporary location say temp1 4) next x + temp1 gets evaluated and the result is assigned back to x. So is the sequence of evaluations correct or am i missing out something here? Would it be correct to assume tht given an expression all unary oerators are evaluated followed by evaluation of binary operators thanks, silpa Jun 2 '07 #1
32 Replies

 P: n/a si****@gmail.com said: hi, i am a bit confused on expression evaluation order in expressions involving unary increment.decrement operators along with binary operators. For example in the following expression x += i + j + k++; is the following the sequence of evaluations 1) as ++ has highest precedencce subexpression k++ gets evaluated No. You can think of precedence and associativity as sorting out which expressions get to be the operands for any given operator. Precedence and associativity rules mean that the above expression has the same meaning as: x += ((i + j) + (k++)); The order of evaluation of the expressions is unspecified. k++ might be done first, or it might not. C doesn't say. What it does say, however, is that the result of k++ is the value k had at the previous sequence point, so it turns out that it doesn't actually matter anyway. I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. Would it be correct to assume tht given an expression all unary oerators are evaluated followed by evaluation of binary operators No. See above. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 2 '07 #2

 P: n/a Richard Heathfield wrote: I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. (fx:nitpick) False, since the P & A determines what's an operand of what, and in general operands have to be evaluated before the operation of which they are a part. But that's only an indirect effect. -- "There's a doorway where there was a wall" /Master Humpries Clock/ Hewlett-Packard Limited registered no: registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England Jun 4 '07 #3

 P: n/a Chris Dollin said: Richard Heathfield wrote: >I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. (fx:nitpick) False, Wrong. since the P & A determines what's an operand of what, True. and in general operands have to be evaluated before the operation of which they are a part. That doesn't matter for my point. For example, consider the expression: a = b() * c() + d(); Here is one legal possibility for the generated assembly language code: JSR _d MOV R20, R10 ; copy result of d() to reg 20 JSR _c MOV R21, R10 ; copy result of c() to reg 21 JSR _b MOV R22, R10 ; copy result of b() to reg 22 MOV R24, 0 ; reg 24 will hold the result of the entire expr ADD R24, R20 MUL R21, R22 ADD R24, R21 ; the calculation is now complete MOV _a, R24 Here, the order of evaluation is d(), c(), b(), addition, multiplication, whereas the precedence and associativity ordering would suggest pretty much the opposite. But that's only an indirect effect. And a misleading one. I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 4 '07 #4

 P: n/a In article <7Z******************************@bt.com>, Richard Heathfield Chris Dollin said: >and in general operands have to be evaluated before theoperation of which they are a part. >That doesn't matter for my point. For example, consider the expression:a = b() * c() + d(); [...] >I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. I think Chris's point is that the relative precedence of + and * forces the multiplication corresponding to the "*" operators to be done before the addition corresponding to the "+" operator, and that was true even in your example code. Of course, you might be able to generate code sufficiently different from the original expression that nothing can be identified as "the addition corresponding to the '+' operator". -- Richard -- "Consideration shall be given to the need for as many as 32 characters in some alphabets" - X3.4, 1963. Jun 4 '07 #5

 P: n/a Richard Tobin said: In article <7Z******************************@bt.com>, Richard Heathfield For example, consider the expression:a = b() * c() + d(); [...] >>I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. I think Chris's point is that the relative precedence of + and * forces the multiplication corresponding to the "*" operators to be done before the addition corresponding to the "+" operator, and that was true even in your example code. My point is that one of the operands of the addition was actually evaluated *first*, despite the fact that precedence and associativity rules would suggest it should actually be evaluated *last* (if they were even remotely relevant). Of course, you might be able to generate code sufficiently different from the original expression that nothing can be identified as "the addition corresponding to the '+' operator". Indeed. In fact, it would be easy - just replace the addition with an AND, an XOR, a LSH, and a jump, with a Russian-peasant-multiplication loop round the outside. Then you can mix all the additions and multiplications up into one sorry mess in which it would be unreasonable to say "this happens, and then that happens", because they overlap so much. I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 4 '07 #6

 P: n/a Richard Heathfield wrote: Chris Dollin said: >Richard Heathfield wrote: >>I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. (fx:nitpick) False, Wrong. >since the P & A determines what's an operand of what, True. >and in general operands have to be evaluated before theoperation of which they are a part. That doesn't matter for my point. For example, consider the expression: a = b() * c() + d(); Here is one legal possibility for the generated assembly language code: (fx:snip) Here, the order of evaluation is d(), c(), b(), addition, multiplication, whereas the precedence and associativity ordering would suggest pretty much the opposite. (fx:nitpick) False. Given the expression b() * c() + d(), it is /exactly/ the precedence that determines that the addition is done after the multiplication (in the C abstract machine) -- because one operand of the addition is the result of the multiplication. It doesn't determine the order of those particular /operands/, of course; that doesn't matter, because of "nitpick" and-jointly "*anything*". (I share with you the idea that it's important for newbies to learn that P&A doesn't determine OOE; but your extreme wording leaves your lesson more subject to attack than a less extreme wording would. IMAO.) -- "You're not supposed to /think/ about it, /The Beiderbeck Connection/ you're supposed to say NO!" Jill Swinburn Hewlett-Packard Limited registered no: registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England Jun 4 '07 #7

 P: n/a In article <2M******************************@bt.com>, Richard Heathfield >>a = b() * c() + d(); >>>I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. >I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, and thatwas true even in your example code. >My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence and associativityrules would suggest it should actually be evaluated *last* (if theywere even remotely relevant). That's not enough to show that precedence has *nothing* to do with evaluation order. b(), c(), and d() can be evaluated in any order, but the addition can't be evaluated before the multiplication. At best you can say there might not be any order, but some orders are not possible. -- Richard -- "Consideration shall be given to the need for as many as 32 characters in some alphabets" - X3.4, 1963. Jun 4 '07 #8

 P: n/a Chris Dollin said: Richard Heathfield wrote: >Chris Dollin said: >>Richard Heathfield wrote:I cannot stress this enough: neither precedence nor associativityhas *anything* to do with order of evaluation.(fx:nitpick) False, Wrong. >>since the P & A determines what's an operand of what, True. >>and in general operands have to be evaluated before theoperation of which they are a part. That doesn't matter for my point. For example, consider theexpression:a = b() * c() + d();Here is one legal possibility for the generated assembly languagecode: (fx:snip) >Here, the order of evaluation is d(), c(), b(), addition,multiplication, whereas the precedence and associativity orderingwould suggest pretty much the opposite. (fx:nitpick) False. Given the expression b() * c() + d(), it is /exactly/ the precedence that determines that the addition is done after the multiplication (in the C abstract machine) -- because one operand of the addition is the result of the multiplication. Neither the C abstract machine nor the Standard impose an order of evaluation on the implementation. For example, 2 * 2 + 2 need not result in any additions or multiplications being carried out. The implementation could easily code this as (2 << 1) | 2 if it wanted. Or even as 6, with no runtime evaluation happening at all! It doesn't determine the order of those particular /operands/, of course; that doesn't matter, because of "nitpick" and-jointly "*anything*". Right - it doesn't determine the order of those operands. Neither does it determine the *order in which they are evaluated*. (I share with you the idea that it's important for newbies to learn that P&A doesn't determine OOE; but your extreme wording leaves your lesson more subject to attack than a less extreme wording would. IMAO.) Oh, attack away, my dear chap - with any luck, you'll prove I'm wrong, and then I'll have learned something. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 4 '07 #9

 P: n/a Richard Tobin said: In article <2M******************************@bt.com>, Richard Heathfield >>>a = b() * c() + d(); >>>>I cannot stress this enough: neither precedence nor associativityhas *anything* to do with order of evaluation. >>I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, and thatwas true even in your example code. >>My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence and associativityrules would suggest it should actually be evaluated *last* (if theywere even remotely relevant). That's not enough to show that precedence has *nothing* to do with evaluation order. b(), c(), and d() can be evaluated in any order, but the addition can't be evaluated before the multiplication. Okay, I agree that I've overstated my case (or at least can't prove I haven't). My apologies to you and Chris. At best you can say there might not be any order, That is the point I was trying to make. but some orders are not possible. I spent a good five minutes trying to construct a counter-example, and failed. This may be due to my lack of imagination, of course, but the more likely explanation is that you are correct. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 4 '07 #10

 P: n/a In article <2M******************************@bt.com>, Richard Heathfield I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. You are correct. Precedence is laid down in the standard Associatively is also defined in the standard The Order of Evaluation is NOT defined in the standard. A line of C code can be evaluated left to right, right to left, middle out or any order. This has caused problems in the past. The most common single method is Left to right. I am not sure if it has a majority though. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Jun 4 '07 #11

 P: n/a Richard Tobin wrote: In article <2M******************************@bt.com>, Richard Heathfield >>a = b() * c() + d(); >>>I cannot stress this enough: neither precedence nor associativity has*anything* to do with order of evaluation. >>I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, and thatwas true even in your example code. >My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence and associativityrules would suggest it should actually be evaluated *last* (if theywere even remotely relevant). That's not enough to show that precedence has *nothing* to do with evaluation order. b(), c(), and d() can be evaluated in any order, but the addition can't be evaluated before the multiplication. At best you can say there might not be any order, but some orders are not possible. Precede the above with #define d() 0 .... or with any definition of d() that allows the optimizer to discover that no side-effects are produced and the value returned is zero. Now, with as straight a face as you can muster, tell us all again that the addition must come after the multiplication. Chances are, the addition will occur at compile time and thus precede the multiplication by a *lot*. Or instead, use #define d() c() .... and suppose a c() that the optimizer can see is "pure." There's a decent chance that the compiler may generate the same code as for a = (b() + 1) * c(); Muster that straight face yet again, please. -- Eric Sosman es*****@acm-dot-org.invalid Jun 4 '07 #12

 P: n/a In article , Richard Heathfield Richard Tobin said: >In article <2M******************************@bt.com>,Richard Heathfield >>>>a = b() * c() + d(); >>>>>I cannot stress this enough: neither precedence nor associativity>has *anything* to do with order of evaluation. >>>I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, and thatwas true even in your example code. >>>My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence and associativityrules would suggest it should actually be evaluated *last* (if theywere even remotely relevant). That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Okay, I agree that I've overstated my case (or at least can't prove Ihaven't). My apologies to you and Chris. >Atbest you can say there might not be any order, That is the point I was trying to make. >but some orders are not possible. I spent a good five minutes trying to construct a counter-example, andfailed. This may be due to my lack of imagination, of course, but themore likely explanation is that you are correct. This one is interesting but a bit of a red herring... http://www.phaedsys.demon.co.uk/chri...swengtips3.htm and http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm It clearly shows that you have to take care. :-) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Jun 4 '07 #13

 P: n/a Eric Sosman wrote: Richard Tobin wrote: >That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Atbest you can say there might not be any order, but some orders arenot possible. Precede the above with #define d() 0 ... or with any definition of d() that allows the optimizer to discover that no side-effects are produced and the value returned is zero. Now, with as straight a face as you can muster, tell us all again that the addition must come after the multiplication. Chances are, the addition will occur at compile time and thus precede the multiplication by a *lot*. Sure. That's invisible to the abstract machine, though, as are all the as-ifs. (I'm interpreting Richard T's "can't" as "can't, in general", which is what I'd mean if I'd written it in this discussion.) -- "There's a doorway where there was a wall" /Master Humpries Clock/ Hewlett-Packard Limited registered no: registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England Jun 4 '07 #14

 P: n/a Chris Dollin wrote: > Richard Heathfield wrote: I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. (fx:nitpick) False, since the P & A determines what's an operand of what, and in general operands have to be evaluated before the operation of which they are a part. But that's only an indirect effect. Yes, in order to evaluate "a + b", the values of "a" and "b" must be determined before the addition takes place. But, there is nothing that says anything about which gets evaluated first. The order of evaluation is not specified. Taking this further: ( a + b ) * ( c - d ) Again, "a" and "b" must be evaluated some time before the addition is done, and "c" and "d" must be evaluated some time before the subtraction is done, and both the addition and subtraction must be[*] done some time before the multiplication is done. However, there is nothing which specifies the order in which a, b, c, and d are evaluated. [*] In fact, as far as I understand it, nothing really requires that "a+b" or "c-d" be evaluated before the multiplication is done, as long as the result is the same. Although inefficient, I believe it is possible for the compiler to treat the above as if it were written as: a*c + b*c - a*d - b*d; as long as any side effects aren't duplicated. -- +-------------------------+--------------------+-----------------------+ | Kenneth J. Brody | www.hvcomputer.com | #include | | kenbrody/at\spamcop.net | www.fptech.com | Jun 4 '07 #15

 P: n/a In article , Eric Sosman That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Atbest you can say there might not be any order, but some orders arenot possible. Precede the above with #define d() 0[...] Well obviously. But all that means is that there are some more cases where the order isn't fixed, when the claim I was addressing is that precedence *never* constrains evaluation order. Richard Heathfield is entirely right to separate precedence and associativity - which apply to the mapping from program syntax to semantics - from evaluation order, which can be chosen in any way that implements the semantics. He just went too far in denying that the syntactic features have *any* consequences for the evaluation order. -- Richard -- "Consideration shall be given to the need for as many as 32 characters in some alphabets" - X3.4, 1963. Jun 4 '07 #16

 P: n/a In article , Chris Hills The Order of Evaluation is NOT defined in the standard.A line of C code can be evaluated left to right, right to left, middleout or any order.This has caused problems in the past. The most common single method isLeft to right. I am not sure if it has a majority though. For most compilers, within an expression, optimisation will choose factors such as making best use of registers, so that choice of syntactic order for equivalent expressions will have little if any effect. -- Richard -- "Consideration shall be given to the need for as many as 32 characters in some alphabets" - X3.4, 1963. Jun 4 '07 #17

 P: n/a Kenneth Brody wrote: Chris Dollin wrote: >>Richard Heathfield wrote: I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. (fx:nitpick) False, since the P & A determines what's an operand ofwhat, and in general operands have to be evaluated before the operationof which they are a part.But that's only an indirect effect. Yes, in order to evaluate "a + b", the values of "a" and "b" must be determined before the addition takes place. But, there is nothing that says anything about which gets evaluated first. The order of evaluation is not specified. The order of evaluation /of the operands/ is not specified; I haven't claimed otherwise. In a + b, there's no room for P & A to make a difference. In a + b * c, without P & A [1] there are two possible unambiguous readings: (a + b) * c, and a + (b * c). In both of these, the order of the evaluation of the /operands/ a, b, c is unspecified. However, in one the result of the addition is an operand of the multiplication, and so /in general/ [2] the addition (not the evaluation of its operands, the addition itself) has to be done before the multiplication; and t'other way about for the other one. [1] And ignoring the detail that C proper doesn't use P&A at all, and the grammar gives an unambiguous reading to a + b * c. [2] ie one can construct /specific/ counter-examples, but without that specicifity you can't assume otherwise. -- "Our future looks secure, but it's all out of our hands." /Man and Machine/ - Magenta Hewlett-Packard Limited Cain Road, Bracknell, registered no: registered office: Berks RG12 1HN 690597 England Jun 4 '07 #18

 P: n/a Richard Tobin wrote: > For most compilers, within an expression, optimisation will choose factors such as making best use of registers, so that choice of syntactic order for equivalent expressions will have little if any effect. I have seen cases where the order of evaluation changed between debug (fast - non optimizing compiler) and release (optimizing compiler). This was at the time when I was not entirely aware that it could change myself and therefore introduced an error - of course the error only existed in the hard to debug release version of the program. Jun 4 '07 #19

 P: n/a Richard Heathfield I cannot stress this enough: neither precedence nor associativity has *anything* to do with order of evaluation. The expression i + j + k++ is evaluated on the virtual machine as (i + j) + k++, not as i + (j + k++). There is potentially a real difference on some machines. Given... #define CONV (-'0') ....and assuming *p is a digit, consider... n = *p + CONV + n * 10; This is a correct form only because there is an implied ordering of evaluation. Without the implied ordering, I would have to use parentheses, or break the statement into multiple statements. [Of course in practice I would write n = n * 10 + (*p - '0'), but that doesn't alter the above comments.] -- Peter Jun 5 '07 #20

 P: n/a Peter Nilsson said: Richard Heathfield sil...@gmail.com said: i am a bit confused on expression evaluation order in expressions involving unary increment.decrement operators along with binary operators. For example in the following expression x += i + j + k++; is the following the sequence of evaluations 1) as ++ has highest precedencce subexpression k++ gets evaluated No. You can think of precedence and associativity as sortingout which expressions get to be the operands for any givenoperator. Precedence and associativity rules mean that theabove expression has the same meaning as:x += ((i + j) + (k++));The order of evaluation of the expressions is unspecified. The order of sub-expressions is unspecified, except for ||, && and ?: operators. As you point out yourself, there is an implied ordering of the + operations from the associativity. I didn't point out any such thing. The associativity determines which operands are used with which operators. That isn't the same as implying an order of evaluation. Any evaluation ordering that happens to fall out of an expression syntax is purely a consequence of reality, and has nothing to do with the rules of C. >I cannot stress this enough: neither precedence norassociativity has *anything* to do with order ofevaluation. The expression i + j + k++ is evaluated on the virtual machine as (i + j) + k++, not as i + (j + k++). There is potentially a real difference on some machines. If the values are initially, say, these: i = 1; j = -1; k = INT_MIN; then there is a real difference in the abstract machine, too. Given... #define CONV (-'0') ...and assuming *p is a digit, consider... n = *p + CONV + n * 10; This is a correct form only because there is an implied ordering of evaluation. Why? Precedence looks perfectly adequate here. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Jun 5 '07 #21

 P: n/a Richard Heathfield wrote: > .... snip ... > Neither the C abstract machine nor the Standard impose an order of evaluation on the implementation. For example, 2 * 2 + 2 need not result in any additions or multiplications being carried out. The implementation could easily code this as (2 << 1) | 2 if it wanted. Or even as 6, with no runtime evaluation happening at all! Now that is overstating things. (2 << 1) is defined as 2 * 2, i.e. as am arithmetic operation. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 6 '07 #22

 P: n/a Chris Dollin wrote: Richard Heathfield wrote: >I cannot stress this enough: neither precedence nor associativityhas *anything* to do with order of evaluation. (fx:nitpick) False, since the P & A determines what's an operand of what, and in general operands have to be evaluated before the operation of which they are a part. But that's only an indirect effect. Oh? For example, with sizeof int == 2, the addition operation could well be simplified to: load lsb1; the digit refers to the variable location add lsb2 store lsbresult; (and save carry) load msb1 adc msb2; note using the carry store msbresult; A carry now implies overflow. and neither operand was pre-evaluated. This will work just fine on simple cpus such as the PIC that have a single 1-byte arithmetic register, the accumulator. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 6 '07 #23

 P: n/a Richard Tobin wrote: Richard Heathfield >>>a = b() * c() + d(); >>>I cannot stress this enough: neither precedence nor associativityhas *anything* to do with order of evaluation. >>I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, andthat was true even in your example code. >My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence andassociativity rules would suggest it should actually be evaluated*last* (if they were even remotely relevant). That's not enough to show that precedence has *nothing* to do with evaluation order. b(), c(), and d() can be evaluated in any order, but the addition can't be evaluated before the multiplication. At best you can say there might not be any order, but some orders are not possible. I think people are missing something. Read my earlier observation on adding (a few minutes ago) first, and then consider A * B in a machine with sizeof int == 2. We do need an 8*8 multiply, and interior carries have to be saved and used. We can form A * B via: lsbA * lsbB + K*(lsbA * msbB + lsbB * msbA) + K*K*(msbA * msbB) and there are better algorithms available. K is related to CHARBIT. So design the 8*8 multiply (when CHARBIT == 8) and you have it all. It helps to have built all this before. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 6 '07 #24

 P: n/a Richard Heathfield

 P: n/a CBFalconer wrote: Richard Tobin wrote: >Richard Heathfield > >>>>a = b() * c() + d(); >>>>I cannot stress this enough: neither precedence nor associativityhas *anything* to do with order of evaluation. >>>I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, andthat was true even in your example code. >>My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence andassociativity rules would suggest it should actually be evaluated*last* (if they were even remotely relevant). That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Atbest you can say there might not be any order, but some orders arenot possible. I think people are missing something. Yes; I have no idea how your post relates to the context; you'll have to unpack the relationship for me. -- "We live for the One, you die for the One." Unsaid /Babylon 5/ Hewlett-Packard Limited registered office: Cain Road, Bracknell, registered no: 690597 England Berks RG12 1HN Jun 6 '07 #26

 P: n/a Chris Dollin wrote: CBFalconer wrote: >Richard Tobin wrote: >>Richard Heathfield >>>a = b() * c() + d();>I cannot stress this enough: neither precedence nor associativity>has *anything* to do with order of evaluation.I think Chris's point is that the relative precedence of + and *forces the multiplication corresponding to the "*" operators to bedone before the addition corresponding to the "+" operator, andthat was true even in your example code.My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence andassociativity rules would suggest it should actually be evaluated*last* (if they were even remotely relevant).That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Atbest you can say there might not be any order, but some orders arenot possible. I think people are missing something. Yes; I have no idea how your post relates to the context; you'll have to unpack the relationship for me. I don't remember the details of the post, and you neglected to quote it. So I have no reply. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 6 '07 #27

 P: n/a CBFalconer wrote: Chris Dollin wrote: >CBFalconer wrote: >>Richard Tobin wrote:Richard Heathfield >a = b() * c() + d();>>I cannot stress this enough: neither precedence nor associativity>>has *anything* to do with order of evaluation.>I think Chris's point is that the relative precedence of + and *>forces the multiplication corresponding to the "*" operators to be>done before the addition corresponding to the "+" operator, and>that was true even in your example code.My point is that one of the operands of the addition was actuallyevaluated *first*, despite the fact that precedence andassociativity rules would suggest it should actually be evaluated*last* (if they were even remotely relevant).That's not enough to show that precedence has *nothing* to do withevaluation order. b(), c(), and d() can be evaluated in any order,but the addition can't be evaluated before the multiplication. Atbest you can say there might not be any order, but some orders arenot possible.I think people are missing something. Yes; I have no idea how your post relates to the context; you'llhave to unpack the relationship for me. I don't remember the details of the post, and you neglected to quote it. So I have no reply. \begin{quote} I think people are missing something. Read my earlier observation on adding (a few minutes ago) first, and then consider A * B in a machine with sizeof int == 2. We do need an 8*8 multiply, and interior carries have to be saved and used. We can form A * B via: lsbA * lsbB + K*(lsbA * msbB + lsbB * msbA) + K*K*(msbA * msbB) and there are better algorithms available. K is related to CHARBIT. So design the 8*8 multiply (when CHARBIT == 8) and you have it all. It helps to have built all this before. \end{quote} I don't see how this relates to precedence vs order-of-evaluation. -- "Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/ Hewlett-Packard Limited registered no: registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England Jun 7 '07 #28

 P: n/a Chris Dollin wrote: > CBFalconer wrote: .... snip ... > >I don't remember the details of the post, and you neglected toquote it. So I have no reply. \begin{quote} I think people are missing something. Read my earlier observation on adding (a few minutes ago) first, and then consider A * B in a machine with sizeof int == 2. We do need an 8*8 multiply, and interior carries have to be saved and used. We can form A * B via: lsbA * lsbB + K*(lsbA * msbB + lsbB * msbA) + K*K*(msbA * msbB) and there are better algorithms available. K is related to CHARBIT. So design the 8*8 multiply (when CHARBIT == 8) and you have it all. It helps to have built all this before. \end{quote} I don't see how this relates to precedence vs order-of-evaluation. Nor do I :-) -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 7 '07 #29

 P: n/a On 4 Jun 2007 at 22:42, CBFalconer wrote: Oh? For example, with sizeof int == 2, the addition operation could well be simplified to: load lsb1; the digit refers to the variable location add lsb2 store lsbresult; (and save carry) load msb1 adc msb2; note using the carry store msbresult; A carry now implies overflow. and neither operand was pre-evaluated. This will work just fine on simple cpus such as the PIC that have a single 1-byte arithmetic register, the accumulator. Assembly is off-topic in c.l.c. So is pseudo-assembly. How (if at all) the implementation chooses to translate code to machine-language is inherently non-portable and non-standard. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Your signature is in gross violation of Usenet conventions and basic netiquette. Please change it. Jun 14 '07 #30

 P: n/a In article , Net Nanny Your signature is in gross violation of Usenet conventions and basicnetiquette. Please change it. Your post was also a gross violation of Usenet conventions and basic Netiquette You must use ONLY ASCII for this NG -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Jun 14 '07 #31

 P: n/a Net Nanny wrote: > On 4 Jun 2007 at 22:42, CBFalconer wrote: Oh? For example, with sizeof int == 2, the addition operation could well be simplified to: [... snip pseudo-assembly example ...] and neither operand was pre-evaluated. This will work just fine on simple cpus such as the PIC that have a single 1-byte arithmetic register, the accumulator. Assembly is off-topic in c.l.c. So is pseudo-assembly. How (if at all) the implementation chooses to translate code to machine-language is inherently non-portable and non-standard. I don't believe it's OT when being used as an example of a valid compilation output, especially when the discussion was about what sort of results are valid. For example, some of the myriad possible outputs for "foo(i++,i++)", or how "i=i++" could result in a frozen computer. Sometimes, the best way to describe a situation is to give some [pseudo-]assembler code. [...] -- +-------------------------+--------------------+-----------------------+ | Kenneth J. Brody | www.hvcomputer.com | #include | | kenbrody/at\spamcop.net | www.fptech.com | Jun 15 '07 #32

 P: n/a On Fri, 15 Jun 2007 10:24:10 -0400, in comp.lang.c , Kenneth Brody Net Nanny wrote: >>Assembly is off-topic in c.l.c. So is pseudo-assembly.How (if at all) the implementation chooses to translate code tomachine-language is inherently non-portable and non-standard. I don't believe it's OT when being used as an example of a validcompilation output, Don't waste your breath - NetNanny is a troll, probably a sockpuppet for one of our resident ones. -- Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan Jun 15 '07 #33

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more C / C++ Questions on Bytes