a reasonable approach to inlining

[Robert Breckinridge Beatie]

In article <11996 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> The dpANS provides for inline generation in a different way:  For
> instance,
> 	#include <math.h>
> 	...
> 		double low; ... low = floor(arg);
> might generate floor inline, while
> 	#include <math.h>
> 	#undef floor
> 	...
> 		double low; ... low = floor(arg);
> will refer to a library routine.
> 
> Note that this makes it difficult to temporarily refer to the library
> version; with #pragma one can presumably turn inlining back on later.
> I do not know whether the dpANS allows a second
> 
> 	#include <math.h>
> 
> to turn floor back into an inline.

It struck me that since preprocessing and translation are supposed to be
"logically successive phases" it might not be necessary to re-include <math.h>
So, the question I'm asking is would it work (portably) to do something like:

	#include <math.h>
	#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

???

This seems ugly as all get out, but I can't think of any reason that it
wouldn't work.  Of course I'm pretty ignorant of the details of the dpANS,
but then that's why I'm asking the question.

So, given that a compiler replaces calls to floor() with inline code, will
that work?
-- 
Breck Beatie	    				(415)856-8649
{uunet,ames!coherent}!aimt!breck
"Sloppy as hell Little Father.  You've embarassed me no end."