Unnecessary Macros

[Liber]

In article <7213 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>A very few of us (it seems) believe that efficiency is not the
>most important thing in the world,

Must be some who programs in the academic environment, not the commercial
environment. :-)

>and that code cleanliness,
>ease of maintenance, the principle of least surprise, etc., are.

But I want BOTH!  Unfortunately, in this instance, C macros are not
powerful enough to give me both.  (I'm wishing more and more that C allowed
a way of allowing macros to act like functions with respect to passing
parameters -- not quite inline functions, but close.)

>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 readability is of that much concern, why not use a language more suited
for the job?  The fact is that one of the reasons C is chosen is because of
its efficiency over other languages.

>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,

Effectively, you would do a tweak.  Personally, I do not believe that
efficiency can be tweaked in to a program; it has to be designed in from
the beginning.  Assuming infinitely fast CPUs and infinite memory are
assumptions that we can no longer afford to make.  Tweaking should be saved
for fixing the *unforseen* bottlenecks.

>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.

Well, if x really is a complicated expression, then the code probably isn't all
that clean anyway.  As long as you always have clean code, you shouldn't
have problems with macros.  It's when you want to make your macros safe
from unclean code that you run into problems.

>I find it intolerable
>if what appears to be a function call fails mysteriously because
>it happens to be implemented as a macro.

Then macros shouldn't look like function calls!  Since C does not
self-document this fact at every macro invocation, you need to set up a
convention that distinguishes macros from functions (ie, all macros that
are not guaranteed to to behave as a function call are denoted in all
caps).


I am not trying to say that I think efficient code is more important than
readable code.  Personally, I would like clean, self-documenting code that
is efficient (the best of all worlds).  In many situations, however, a
tradeoff needs to be made, and this tradeoff should not be resolved by
blanket statements such as "Efficiency is better than readability" (or
vice-versa).

What we have found with C macros is that they are not good for all the
situations we want to use them for.  They are inadequate replacements for
function calls; the question is:  is it worth modifying them to make them
more useful?  IMHO, I think that this would be a good thing (for ANSI C II
:-)).
-- 
 _ __		NEVIN J. LIBER  ..!att!ihlpb!nevin1  (312) 979-4751  IH 4F-410
' )  )  "I catch him with a left hook. He eels over. It was a fluke, but there
 /  / _ , __o  ____  he was, lying on the deck, flat as a mackerel - kelpless!"
/  (_</_\/ <__/ / <_	These are NOT AT&T's opinions; let them make their own.