Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!ig!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <17154@megaron.cs.arizona.edu>
Date: 24 Jan 90 19:15:23 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 35

In article  <2806@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes:
>In article <4540@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>>In article <14199@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>>> ... [a lot deleted]
> [about order of evaluation]
>>>Fortran (pascal, Modula2, ADA, ...) lets me do so
>>>with parenthesis - C forces me to introduce temporary variables and
>>>_hope_ that the optimizer doesn't actually do a store/load.
>>
>>Read your standards.  ANSI-C (a reality, now) has requirements for
>>order-of-evaluation, much to my chagrin. [...]
>                      ^^^^^^^^^^^^^^^^^^
>I hope the standard has left at least one other anti-mathematic trick
>still intact for your enjoyment, namely that a leading zero changes
>the meaning of a numeric literal (to octal).

Just a note for the Fortran partisans, extra parens occur all the time
in C when the programmer has no intention of specifying the order of
evaluation.   In particular, you should always parenthisize macros:

#define next(x) ((x) + 1)
...
  foo = next(x) + 100

In this example, one would hope that the optimizer would ignore the
parens and compile the last expression as

  foo = x + 101

P.S. I agree that the form of octals is a pretty bad misfeature...
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman