Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!udel!rochester!kodak!uupsi!grebyn!ckp From: ckp@grebyn.com (Checkpoint Technologies) Newsgroups: comp.lang.c Subject: Re: Side Effects Message-ID: <1991Apr6.143523.10443@grebyn.com> Date: 6 Apr 91 14:35:23 GMT References: <1991Apr5.163209.25118@mccc.edu> Organization: Grebyn Timesharing Lines: 33 In article <1991Apr5.163209.25118@mccc.edu> pjh@mccc.edu (Peter J. Holsberg) writes: >The other day I posted about operator assignments and side effects, and >today received the following response that I would like your *posted* >comments on. > >> When in doubt, use "long-hand" and let the compiler optimize. ...except that the C language definition tells you when you are in doubt, by stating which constructions are "undefined". >>If you have >> existing code which you are trying to decypher, you should write a test >> program for your particular compiler because while there is a "correct" >> order of evaluation, it is not necessarily adheared to. I must interpret this to mean, if you are given a program to decode which uses undefined effects, and you must clean it up, then you need to discover the actual effects which the compiler is generating. Then you break the code into well-defined effects that the language spec guarantees. When you find a compiler which does not adhere to the "correct" order of evaluation, then it is a bad, defective compiler. As to the order of side effects in an expression, the language spec says that they're undefined in most cases (sequence is guaranteed for "," "&&", "||" but for nothing else; and by "," I mean the comma operator, NOT the comma separating function parameters) so good, correct compilers are free to interpret as they choose. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / ckp@grebyn.com \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/