Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!phao.eng.ohio-state.edu!rob
From: rob@phao.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Re: Unnecessary Macros (was Re: Unnecessary Parenthesis)
Message-ID: <711@accelerator.eng.ohio-state.edu>
Date: 5 Oct 88 16:59:41 GMT
References: <701@accelerator.eng.ohio-state.edu) <855@goofy.megatest.UUCP>
Sender: news@accelerator.eng.ohio-state.edu
Reply-To: rob@phao.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 33

In article <855@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <701@accelerator.eng.ohio-state.edu), by rob@kaa.eng.ohio-state.edu (Rob Carriere):
>)[...]
>) temp = sin( x );
>) foo = temp*temp + 1.7;
>) 
>) is clearly less legible.
>     ^^^^^^^ ^^^^ ^^^^^^^
>
>To me it is clearly much more legible, becuase I don't have to worry
>about whether "square" has side-effects!

I should have stated the assumption that ``square'' was some
well-defined system function/macro/whatever (don't leave your math
library without one!).  Otherwise, you sure have a good point.

>Always restrict the scope of variables as strictly as possible.

Amen.

>(If the compiler were smart enough to know that sin() has no side-effects,
> it could transform " foo = sin(x)*sin(x) + 1.7 " into the code I
> prefer by means of "common subexpression removal".)

Yes, but I can't rely on the compiler being smart, unless I like nasty
surprises.  Also, while I can check ``sin(x) is the same as sin(x)''
readily enough, it rapidly gets worse with more complicated
expressions.  This is essentially the same thing the *= operator
&friends solve for assignments.  In the same vein, if the expression
gets nasty enough that I need several temporaries, I may get to the
point where I can't see the expression for the temporaries.

Rob Carriere