Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!genrad!panda!talcott!harvard!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.lang.c
Subject: Re: Order of evaluation
Message-ID: <692@terak.UUCP>
Date: Fri, 30-Aug-85 14:01:29 EDT
Article-I.D.: terak.692
Posted: Fri Aug 30 14:01:29 1985
Date-Received: Sun, 1-Sep-85 13:27:11 EDT
References: <764@dataio.UUCP>
Organization: Calcomp Display Products Division, Scottsdale, AZ, USA
Lines: 17

> >OK, I understand that order of evaluation is not guaranteed.  I assume that
> >was done to make compilers easier to write.  Is there any other reason?  Does
> >it really make compilers easier to write?
> 
> Also, allowing the compiler to reorder the expression within certain
> limits allows it to do some optimizations. Most code is not affected by
> order of evaluation, and C does allow an order to be forced (by assigning
> an explicit temporary), so I think this is very reasonable.

What drives me up a wall is that C does *not* allow an order to be
forced by using parentheses!  The compiler is at liberty to ignore
parens which group operators of the same precedence.  <e.g. a+(b+c)>

I don't think much of the notion of having to store intermediate results
just to get the correct answer.
-- 
Doug Pardee -- CalComp -- {seismo!noao,decvax!noao,ihnp4}!terak!doug