Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!scs From: scs@athena.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: Unnecessary Macros (was Re: Unn Message-ID: <7213@bloom-beacon.MIT.EDU> Date: 28 Sep 88 01:24:38 GMT References: <70279@sun.uucp> <225800075@uxe.cso.uiuc.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Lines: 39 In article <225800075@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>>In article <23@datcon.UUCP> sar@datcon.co.uk (Simon A Reap) writes: >>>> z = square(x) + square(y); > >>Maybe I'm missing the point, but why does a good old fashion function seem >>to be out of the question. > >I certainly hope you aren't a programmer. The answer is blatently >obvious: calling overhead. Why in the would would anyone ever even >consider writing a function call to perform a single multiplication? I certainly hope you aren't a programmer! :-) A very few of us (it seems) believe that efficiency is not the most important thing in the world, and that code cleanliness, ease of maintenance, the principle of least surprise, etc., are. We would write a function call to perform a single multiplication precisely because the hacker's solution (use a macro) has so many potential unpleasant surprises, as indicated by this discussion. If (and only if) after-the-fact profiling revealed that the function call overhead was the cause of noticeable and undesirable inefficiency, would we replace it with something quicker, probably the explicit x*x Doug recommended, introducing an explicit temporary (i.e. not trying to get the preprocessor to do it for us) if x was a complicated expression or involved side effects. I know there are many people who think that efficiency _i_s the most important thing in the world. (Someone called Andrew Koenig's, I believe, attitude "execrable" for advocating cleanliness over efficiency.) It boils down to a question of priorities. Some find it intolerable if something simple like squaring involves function call overhead. I find it intolerable if what appears to be a function call fails mysteriously because it happens to be implemented as a macro. Steve Summit scs@adam.pika.mit.edu