TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU (12/19/87)
First of all, I'm all for noalias. It helps generate faster
code for those who know how to use it. It's like register;
if you don't know how to use it... DON'T USE IT. Why
all the debate? It simply is a warning to the compiler
that there are never going to be pointers to that object
that will change the value "behind the compilers back".
(actually, it says that there's no pointers that will
not change it either)
Second of all, I *HATE* the decision about parenthesis. K&R says
that if the compiler can generate better code by re-writing
"(A+B)+C" to become "(A+C)+B" and now ANSI is saying no. I guess
if functions a(), b() and c() have side effects ( a()+b() ) + c()
shouldn't be allowed to be re-grouped but why penilize the
programmers who don't use side effects. This isn't encouraging
programmers to use side effects but it isn't helping either.
What happened to setting up a method of stateing "don't re-group me".
I know a #pragma was suggested but a lot of people don't like
pragmas. What happened to the suggestion about a unary plus?
I see no problem with +( a()+b() ) + c() as a very clean method.
(I also think my macros may be nicer if I had a unary plus).
What really makes me not like this idea is the fact that I see
a lot of room for optimization when I realize that a[i] is *(a+i).
One of the reasons that "typical C" is faster than "typical
pascal" (Ummm... note I say "typical"... I'm making a generalization
here. No flames please) is that pascal people loop i from a to b
and process c[i]. That's a lot of (c+i)'s going on. In C generally
you do i=&a and loop to &b. When I do complex array processing
(a lot of my string work) I will now wonder what the optimizer
is NOT doing.
Someone stated (sorry, I forgot your name) that ANSI has given
us a new road to better code and removed anther. I agree.
I think that removing this feature of C is the ONLY thing that
ANSI has done that I don't like so far. This is certainly a
pretty good hit ratio. Congradulations.
Tom Limoncelli
BITNET: tlimonce@drew LIFE: Drew U/Box 1060/Madison NJ/07940
Disclaimer: Don't believe me. It only encourages me to write more.
--------------------------------------------------------------------gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/20/87)
In article <10917@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: >What happened to the suggestion about a unary plus? Unary plus is still in the language, but it no longer requires a special non-regrouping guarantee. Its behavior is the same as before. Its main reason for existence now is to permit tables of constant initializers to be written like: -123.45 +987.65 (Neither the + nor - are part of the number; they're operators!) I.e., simply for reasons of symmetry. Believe me, X3J11 was resisting the clamor for "parentheses grouping enforced" (which is actually a slight misrepresentation of the issue) for as long as possible, but finally two things occurred to change our position on this: (1) Realization that optimization would not be hurt on many popular architectures; (2) Insistence on the part of an ISO member, that could have blocked adoption of ANSI C as an ISO standard. Thanks for the comments.
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (12/22/87)
In article <10917@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes: > Second of all, I *HATE* the decision about parenthesis. K&R says > that if the compiler can generate better code by re-writing > "(A+B)+C" to become "(A+C)+B" and now ANSI is saying no. I guess > if functions a(), b() and c() have side effects ( a()+b() ) + c() > shouldn't be allowed to be re-grouped but why penilize the > programmers who don't use side effects. In ( a() + b() ) + c() the parentheses now say that the first addition must be performed before the second. It does not say (I least I hope it doesn't) that a() and b() must be evaluated before c(). Compilers should still be free to make the function calls in any of the 6 possible orders, so long as the RESULTS of a() and b() are ADDED, but not necessarily EVALUATED, first. > but why penilize the programmers who don't use side effects. ^^^^^^^^ Does this imply that programmers who don't use side effects are lacking part of their anatomy, and that ANSI is going to repair this deficiency? Is that why some of them are known as "unix programmers"?