Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!coherent!aimt!breck
From: breck@aimt.UUCP (Robert Breckinridge Beatie)
Newsgroups: comp.lang.c
Subject: Re: a reasonable approach to inlining
Summary: a question regarding disabling inline functions
Message-ID: <1087@aimt.UUCP>
Date: 17 Jun 88 05:02:35 GMT
References: <238@chem.ucsd.EDU> <2742@utastro.UUCP> <225800036@uxe.cso.uiuc.edu> <11996@mimsy.UUCP>
Organization: AIM Technology, Palo Alto, CA
Lines: 44

In article <11996@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> The dpANS provides for inline generation in a different way:  For
> instance,
> 	#include 
> 	...
> 		double low; ... low = floor(arg);
> might generate floor inline, while
> 	#include 
> 	#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 
> 
> 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 
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

???

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."