kent@xanth.UUCP (04/11/87)
In article <995@wanginst.EDU> mckeeman@wanginst.EDU (William McKeeman) writes: >I am a bit frustrated by people talking past each other on this topic. The >order of evaluation rules in C are a blanket over several subproblems. >Conclusion: when making a pitch for a better C definition rule, identify >which of the problems: > unrestricted optimization > overflow anomalies > roundoff anomalies > side effect anomalies >it is designed to solve. If you don't intend for your rule to have >language-wide implications, state the limited area of application. >-- >W. M. McKeeman mckeeman@WangInst >Wang Institute decvax!wanginst!mckeeman >Tyngsboro MA 01879 I agree that this is an excellent idea, and, being nothing if not opinionated, and having freely confessed my disenchantment with C in its present state in this forum previously, I will start this discussion off with four new subjects corresponding to (Mr., Mrs., Miss, Ms., Dr., (?)) McKeeman's plan, and then sit back and read the responses. The typical paradigmatic side expression problem due to unspecified order of execution is: int a[4]={0,0,0,0}, b[4]={0,1,2,3}, i=0; a[++i] = b[++i] + ++i; printf ("%d,%d,%d,%d,%d,%d,%d,%d,%d\0", a[0],a[1],a[2],a[3],b[0],b[1],b[2],b[3],i); where the ambiguity of the order in which the ++i operations are done makes the printed result anybodys guess. (If the syntax is wrong, it's very late here, please forgive.) I'll really try to hold it down on this one, because I think the side effects weirdness in C is what makes it possible to be a guru and keep the riff-raff out. Of course, since I frequently feel like one of the C riff-raff, perhaps I should raise a few objections here. I won't, because I feel that this problem is already solved in C, in that it really is possible to just pull the side effect causing stuff out into a separate statement, put it after the loop, or whatever, and _not_ have to worry that an optimizing compiler will take your unambiguous case and reorder it back into the ambiguous case you wanted to avoid. For example, in the above case, all the ambiguity is removed by replacing: a[++i] = b[++i] + ++i; by: a[i+1] = b[i+2] + i+3; i += 3; if that is what was desired. Comments? Kent. -- The Contradictor Member HUP (Happily Unemployed Programmers) // Also // A Back at ODU to learn how to program better (after 25 years!) \\ // Happy \// Amigan! UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Copyright 1987 Kent Paul Dolan. How about if we keep the human All Rights Reserved. Author grants race around long enough to see retransmission rights recursively only. a bit more of the universe?