Unnecessary Macros (was Re: Unnecessary Parenthesis)

Joe English english at stromboli.usc.edu
Tue Oct 4 12:17:26 AEST 1988


In article <701 at accelerator.eng.ohio-state.edu> rob at kaa.eng.ohio-state.edu (Rob Carriere) writes:
>In article <8590 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>One wonders whether [the inability to define a square macro] is much of a
>>problem.
>
>How about the following, deep in some inner loop:
>foo = square( sin( x )) + 1.7;
>I *don't* want to write:
>foo = sin( x )*sin( x ) + 1.7;
>

Why not?  Unless you're using square() for legibility, the macro
expansion is going to be sin(x) * sin(x) anyway.

As long as I'm posting, I might as well throw in my two cents' worth, too:
I never, ever write a macro whose behaviour is not identical to a
function call (or to a constant), simply because of the dangers of
side-effects being performed twice.  If I want the "right" syntax, I
write it as a function, and if I need optimization, I expand it
manually.  

Tightly optimized code is not always pretty, nor does it have to be.
The best solution I've found when writing code optimized to the point
of obfuscation is to precede it with a comment:

/* WARNING: THE FOLLOWING CODE LOOKS AWFUL! DFWI! */ 

It doesn't enhance the readability, but it at least reminds me to be
careful when modifying it.

--
      /|/| "What do you look for in a quote?"
-----< | |                                   --Jay Hinkelman
  O   \|\| english%lipari at oberon.usc.edu



More information about the Comp.lang.c mailing list