Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: a reasonable approach to inlining
Message-ID: <1181@mcgill-vision.UUCP>
Date: 25 Jun 88 07:39:23 GMT
References: <238@chem.ucsd.EDU> <2742@utastro.UUCP> <225800036@uxe.cso.uiuc.edu> <1087@aimt.UUCP>
Organization: McGill University, Montreal
Lines: 71

In article <1087@aimt.UUCP>, breck@aimt.UUCP (Robert Breckinridge Beatie) writes:
> In article <11996@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
>> [about inlining functions and how it can be suppressed]
>> Note that this makes it difficult to temporarily refer to the
>> library version; [...]  I do not know whether the dpANS allows a
>> second  #include   to turn floor back into an inline.
> So, the question I'm asking is would it work (portably) to do
> something like:
> 	#include 
> 	#define TEMP floor
> 	#undef floor		/* should turn off inlining for floor */
> 	...
> 		double low; ... low = floor(arg);
> 	#define floor TEMP	/* hopefully turns inlining back on */
> 	#undef TEMP

No, this wouldn't work....  Let's see what happens to

#include 
#define TEMP floor
#undef floor
floor(foo);
#define floor TEMP
#undef TEMP
floor(foo);

in the preprocessor.  (I'm concerned with just the preprocessor here,
so I didn't bother putting the above in a function body.)

Let's see what happens to the first floor(foo);.  First it gets
tokenized:

	floor ( foo ) ;

This is scanned for macros.  None are found, so we get those five
tokens in the output stream of the preprocessor.

Now, the second one:

	floor ( foo ) ;

Aha, floor is defined.  What's it defined as?  TEMP.

	TEMP ( foo ) ;

There are no further defined names there (we #undefined TEMP).  So it
now turns into a function call to TEMP, whatever that is.

> This seems ugly as all get out, but I can't think of any reason that
> it wouldn't work.

You seem to be expecting the preprocessor to behave a bit differently
from the way it really does.  When a macro is defined in terms of
another macro (or macros), the expansion is not scanned for other
definitions at the time of the #define, but rather after expanding the
macro.  For example, the following produces "foo", not "bar":

#define XXX bar
#define YYY XXX
#define XXX foo
YYY

As far as I know, there is no way to force the preprocessor to expand
macros in the replacement text of a definition at the time the #define
is done rather than at the time the macro is used.  This might be a
useful feature; does it exist anywhere at present?

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu