424,950 Members | 1,005 Online Need help? Post your question and get tips & solutions from a community of 424,950 IT Pros & Developers. It's quick & easy.

Purpose of sequence points

 P: n/a Hi all! I do not have a standard-document right next to me to cite from, but as far as I know, doing something like: a()=b()=c()=d(); or foo(d()+c()+b()+a()); has a fixed evaluation order (right-to-left in the first case and left-to-right in the second one), although there are no sequence points inside the =- or +-expression. (Please correct me if I'm wrong here) So, other than the order of evaluation of arguments to a function call: foo(a(), b(), c(), d()); a, b, c and should be called in reverse order (d, c, b, a) for my first two examples, right? For the third one, it is unspecified, AFAIK. But when I do something like: a=b=a=b or (++a)+(a++) this is invalid due to multiple modification inbetween sequence points. So here my question: What is the purpose of this rule, as in these cases the order is well defined despite the fact there are no sequence points? Is this to help the compiler optimize or could real ambiguities occur? Yours, Daniel -- Got two Dear-Daniel-Instant Messages by MSN, associate ICQ with stress -- so please use good, old E-MAIL! Jun 15 '07 #1
4 Replies

 P: n/a Daniel Kraft wrote: Hi all! I do not have a standard-document right next to me to cite from, but as far as I know, doing something like: a()=b()=c()=d(); or foo(d()+c()+b()+a()); has a fixed evaluation order (right-to-left in the first case and left-to-right in the second one), although there are no sequence points inside the =- or +-expression. (Please correct me if I'm wrong here) You're wrong. The compiler is free to calculate the operands a(), b(), c(), and d() in any order. The order of the *arithmetic calculation* is defined. The compiler can say "calcluate b(), then a(), then c(), then d(), and store them in temps b, a, c, d, respecitvely. Then evaluate ((d + c) + b) +a. So the associativity and precedence of the operations is defined, but the order of evaluation of the operands isn't. Jun 15 '07 #2

 P: n/a red floyd wrote: Daniel Kraft wrote: >Hi all!I do not have a standard-document right next to me to cite from, butas far as I know, doing something like:a()=b()=c()=d();orfoo(d()+c()+b()+a());has a fixed evaluation order (right-to-left in the first case andleft-to-right in the second one), although there are no sequencepoints inside the =- or +-expression.(Please correct me if I'm wrong here) You're wrong. The compiler is free to calculate the operands a(), b(), c(), and d() in any order. The order of the *arithmetic calculation* is defined. The compiler can say "calcluate b(), then a(), then c(), then d(), and store them in temps b, a, c, d, respecitvely. Then evaluate ((d + c) + b) +a. So the associativity and precedence of the operations is defined, but the order of evaluation of the operands isn't. I see -- but what is this restriction really for? To help the compiler optimize the code? At least this is the only reason I can think of. (Of course, this isn't really a restriction which hurts much; but it's surely not there just for the sake of restricting the language) Yours, Daniel -- Got two Dear-Daniel-Instant Messages by MSN, associate ICQ with stress -- so please use good, old E-MAIL! Jun 15 '07 #3

 P: n/a Daniel Kraft wrote: red floyd wrote: >Daniel Kraft wrote: >>Hi all!I do not have a standard-document right next to me to cite from, butas far as I know, doing something like:a()=b()=c()=d();orfoo(d()+c()+b()+a());has a fixed evaluation order (right-to-left in the first case andleft-to-right in the second one), although there are no sequencepoints inside the =- or +-expression.(Please correct me if I'm wrong here) You're wrong. The compiler is free to calculate the operands a(),b(), c(), and d() in any order. The order of the *arithmeticcalculation* is defined. The compiler can say "calcluate b(), thena(), then c(), then d(), and store them in temps b, a, c, d,respecitvely. Then evaluate ((d + c) + b) +a. So the associativityand precedence of the operations is defined, but the order ofevaluation of the operands isn't. I see -- but what is this restriction really for? It's not a restriction. It would be a restriction if the order were prescribed. Since it's unspecified, it's a non-restriction (what's the antonym of 'restriction'?) To help the compiler optimize the code? At least this is the only reason I can think of. Not to help optimise but rather not to impede possible optimisations. (Of course, this isn't really a restriction which hurts much; but it's surely not there just for the sake of restricting the language) It's there for exactly the opposite purpose - of NOT restricting. V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask Jun 15 '07 #4

 P: n/a On Jun 15, 8:47 pm, Daniel Kraft 