Unnecessary Macros (was Re: Unn

[Steve Summit]

In article <225800075 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>>>In article <23 at datcon.UUCP> sar at 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 at adam.pika.mit.edu