Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!sm.unisys.com!oberon!stromboli.usc.edu!english From: english@stromboli.usc.edu (Joe English) Newsgroups: comp.lang.c Subject: Re: Unnecessary Macros (was Re: Unnecessary Parenthesis) Message-ID: <12546@oberon.USC.EDU> Date: 4 Oct 88 02:17:26 GMT References: <2089@ssc-vax.UUCP> <441@kaon.uchicago.edu> <1401@devsys.oakhill.UUCP> <23@datcon.UUCP> <8577@smoke.ARPA> <8078@haddock.ima.isc.com> <8590@smoke.ARPA> <701@accelerator.eng.ohio-state.edu> Sender: news@oberon.USC.EDU Reply-To: english@stromboli.usc.edu (Joe English) Distribution: na Organization: University of Southern California, Los Angeles, CA Lines: 34 In article <701@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes: >In article <8590@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) 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@oberon.usc.edu