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 #includeto 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