Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!eneevax!umd5!brl-adm!adm!dsill@NSWC-OAS.arpa
From: dsill@NSWC-OAS.arpa
Newsgroups: comp.lang.c
Subject: Re: Optimizing Floating-Point Expression Evaluation
Message-ID: <7262@brl-adm.ARPA>
Date: Wed, 6-May-87 13:18:30 EDT
Article-I.D.: brl-adm.7262
Posted: Wed May  6 13:18:30 1987
Date-Received: Fri, 8-May-87 04:13:22 EDT
Sender: news@brl-adm.ARPA
Lines: 37

Jim Valerio <jimv@omepd> wrote:
>And now back to:
>(3) Should macros behave like functions rather than simple textual
>    substitutions?

No, macros are macros and they should behave like macros.

>I guess I wish that the C preprocessor was more tightly integrated into
>the language so arguments to macros would have an implied precedence.
>Then I wouldn't need to introduce the extra parentheses that I wouldn't
>write if I were writing out the expression longhand.  For example, if
>the macro substitution were done after the expression tree for an
>expression involving a macro was constructed, then
>	#define islower(ch)	ch >= 'a' && ch <= 'z'
>would work for
>	islower(c)		/* normally wouldn't put ()'s here */
>and
>	islower(c & 0x7f)	/* islower def *wants* ()'s now */

A better solution, which I saw in a magazine once upon a time, is a for
mechanism using "inline" functions.  These functions are defined like
normal functions but with the storage class ``inline''.  So islower
would be declared something like:

inline islower(ch)
char ch;
{
    return (ch >= 'a' && ch <= 'z');
}

The difference is that the code for islower would be generated at each
place the function is called, thus avoiding the function call overhead.
I haven't followed the X3J11 committee very closely, so I don't know if
this was even considered.

-Dave Sill
 dsill@nswc-oas.arpa