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