Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!sri-unix!sri-spam!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!otter!kers From: kers@otter.HP.COM (Christopher Dollin) Newsgroups: comp.lang.c Subject: Re: Autoincrement question Message-ID: <1670001@otter.HP.COM> Date: Tue, 8-Dec-87 03:18:23 EST Article-I.D.: otter.1670001 Posted: Tue Dec 8 03:18:23 1987 Date-Received: Sun, 13-Dec-87 11:40:31 EST References: <1507@ogcvax.UUCP> Organization: hplabs-brc Bristol,UK. Lines: 26 david@elroy.Jpl.Nasa.Gov (David Robinson) says: >What are the current arguments against having the ANSI stndard >defining the order of evaluation of the assignment operator? >I can understand that the evaluation of one side being left >as implementation dependant for efficency purposes but a >require ment that "right hand side fully evaluated, then left >hand side fully evaluated BEFORE assignment" would solve the >"a[i++] = i * 2;" problem without unduly restricting the >compiler writers. Well, I've written compilers (not for C), and you'd be surprised at how much of a restriction that sort of ordering can be if you're trying to generate good code. Depending on the target machines instruction set, it can really cripple your code generator. The problem is that 127 times out of 128, the order really doesn't matter, and the compiler can use this to generate the "best" code for that sequence; the other 1 time isn't really worth catering for. I also think that depending on implict control flow rules such as that above can produce opaque code. But then, who bothers about maintaing C anyway :-) Regards, Kers | "Why Lisp when you can talk Poperly?"