Path: utzoo!utgpu!water!watmath!clyde!att!ihlpb!nevin1 From: nevin1@ihlpb.ATT.COM (Liber) Newsgroups: comp.lang.c Subject: Re: Unnecessary Macros (was Re: Unnecessary Parenthesis) Message-ID: <8813@ihlpb.ATT.COM> Date: 29 Sep 88 00:18:01 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> <70279@sun.uucp> <7173@aw.sei.cmu.edu> Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 26 In article <7173@aw.sei.cmu.edu> firth@bd.sei.cmu.edu (Robert Firth) writes: >>[several ways to define "square(x)" in C that don't quite work] >Full circle, I think. We're about back where we started with the >position that the only effective solution is an exponentiation >operator, and let the compiler do the grunt work. In other words, there is no solution within the framework of C. There are a number of large number of functions that I would rather have as macros (especially when I have the same operation for different argument types), but can't because I'm not allowed to (in general) assume that parameters passed will behave as simple variables w/o side effects. Just fixing the problem by changing square(x) to an operator (no, I DON'T want to start up that discussion again!) doesn't help with the more general problem, and is, in effect, just another kludge to C. What is really wanted is to be able to declare macros so that it would have the same semantics as an inlined function would (somewhat like C++ inlining, except that type checking would not be done on the arguments. Then again, maybe type checking ought to be done on the arguments...). When do the proposals for dpANS C II start? :-) -- _ __ 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!" / (_