Order of evaluation and optimizing code

[H. Munster]

I've read a number of letters in this column recently from people who would
like to see C obey a strict left-to-right, inside-to-outside order of
evaluation. I wonder if they realize how much this sort of thing cripples
compilers in trying to optimize code. C is one of the best, if not *the*
best languages in terms of compiled-code efficiency, and much of this is
due to the language standard allowing compilers to rearrange expressions
as they see fit, to eliminate redundant calculations and take advantage of
machine quirks and dependencies. Please don't change it!

While on the subject, I have read about the proposed ANSI convention for
forcing evaluation "sequence points" by using the unary plus sign, and
I don't know how much I like it. It does preserve compatibility in the
sense that code that uses it will compile on a compiler that doesn't know
about it...but will the compiled code work? If the compiler does not
realize the significance of the unary plus and doesn't maintain the specified
order of evaluation, is the compiled code going to work? Probably not.
Then the person who is doing the port has to scratch their head and try
to figure out what the problem is. And, if they're not familiar with
the unary-plus convention, it's going to take a very long time to straighten
out. I think that, in this case, it might have been better to invent a
new keyword or symbol to designate a sequence point, so that if the code
is ported to a compiler that doesn't have it, the problem will become
apparent immediately. And before you send me a flame saying "BUT THAT
WOULDN'T BE C!!!!", remember that Berkeley and other institutions have
already taken it upon themselves to add things that aren't in the
original K&R spec, such as structure assignment. Are you going to tell
me that a compiler which allows structure assignment "isn't a C compiler"?

---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt
or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."

[Doug Gwyn]

In article <1...@houligan.UUCP> Dave Cornutt writes:
-... If the compiler does not
-realize the significance of the unary plus and doesn't maintain the specified
-order of evaluation, is the compiled code going to work? ...
-... it might have been better to invent a
-new keyword or symbol to designate a sequence point, so that if the code
-is ported to a compiler that doesn't have it, the problem will become
-apparent immediately.

How about the symbol + which isn't a valid unary operator in K&R C?

In other words, unary + DOES meet your concerns.

[Henry Spencer]

> ...It does preserve compatibility in the
> sense that code that uses it will compiler on a compiler that doesn't know

> about it...but will the compiled code work? If the compiler does not
> realize the significance of the unary plus and doesn't maintain the specified
> order of evaluation, is the compiled code going to work? Probably not.

Not a problem, because it *won't* compile on a compiler that doesn't know
about it. Pre-X3J11 C does not have a unary plus operator!

> ...remember that Berkeley and other institutions have

> already taken it upon themselves to add things that aren't in the
> original K&R spec, such as structure assignment. Are you going to tell
> me that a compiler which allows structure assignment "isn't a C compiler"?

Sorry, you are mistaken about the history. Structure assignment came from
Dennis Ritchie & Co. at Bell Labs, the originators of C. If you doubt me,
find a V7 Unix manual and look at the one-page addendum to the C Reference
Manual. K&R slightly predates V7, and hence doesn't mention it. (For that
matter, V7 was not the last word on C evolution within Bell, as you will
see if you compare the V7 C manual with the SysV C manual: no, "void"
and "unsigned char" and such were *not* invented by Berkeley.)

There have actually been remarkably few non-standard additions to C by
compiler writers -- a considerable tribute to Dennis's skill at devising
a language that lets you do what you want.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry