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?"