Path: utzoo!utgpu!water!watmath!clyde!att!ihlpb!nevin1 From: nevin1@ihlpb.ATT.COM (Liber) Newsgroups: comp.lang.c Subject: Re: Unnecessary Macros Message-ID: <8814@ihlpb.ATT.COM> Date: 29 Sep 88 01:15:21 GMT References: <70279@sun.uucp> <225800075@uxe.cso.uiuc.edu> <7213@bloom-beacon.MIT.EDU> Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 72 In article <7213@bloom-beacon.MIT.EDU> scs@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!" / (_