adam@visix.com (03/27/91)
Hi, a quick question -- Given today's C compilers, is there any reason at all to explicitly inline code with macros? The only thing I could think of was there might be cases where you want explicit control of the space/time tradeoff (but surely the benefit is small). Assuming that's useful, is there any use for subroutines, so that a routine is only inlined once per function? (I.e. would this be a useful third choice on the space/time tradeoff?) (surely this benefit is even smaller). (Actually, I don't see any way to pass arguments to and return from subroutines that would make them useful in C.) Thanks much, Adam adam@visix.com
ckp@grebyn.com (Checkpoint Technologies) (03/28/91)
In article <1991Mar27.024602.21399@visix.com> adam@visix.com writes: > >Hi, a quick question -- > >Given today's C compilers, is there any reason at all to explicitly >inline code with macros? I think so. In-lining with macros always works, so you are insulating yourself from the compiler's quality somewhat. I also notice that more "advanced" implementations (GCC, C++) give you an "inline" keyword, rather than improve their own automatic inlining quality. But of course this is only my opinion. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / ckp@grebyn.com \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
gwyn@smoke.brl.mil (Doug Gwyn) (03/28/91)
In article <1991Mar27.024602.21399@visix.com> adam@visix.com writes: >Given today's C compilers, is there any reason at all to explicitly >inline code with macros? Sure -- many of today's C compilers still don't inline functions. >Assuming that's useful, is there any use for subroutines, so that a >routine is only inlined once per function? Rephrasing this to make sense, I guess you're asking whether if a function is invoked only once there is any point to having it an actual function rather than a macro (or in-lined). The answer to that is, yes, it helps immensely when using a typical debugger. >(Actually, I don't see any way to pass arguments to and return from >subroutines that would make them useful in C.) ???
adam@visix.com (03/28/91)
In article <1991Mar27.024602.21399@visix.com> I wrote: -> Assuming that's useful, is there any use for subroutines, so that a -> routine is only inlined once per function? : : -> (Actually, I don't see any way to pass arguments to and return from -> subroutines that would make them useful in C.) In article <15601@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > ??? Oops! Normally I am really quite intelligible, sorry about that. I've been playing with the idea of a toy preprocessor to provide some automagic premangling of my C source. Among other things, I thought it would be nice to automatically generate inlining macros from existing function definitions (if inlining is useful). Now, given inlining, I wondered, what if a two-line function gets inlined twenty times in one function? Wouldn't it be more efficient to inline the actual code only once, with a label, and then expand calls to it into goto's to the label? Since the goto itself doesn't push any arguments, I called this option a subroutine, out of analogy to BASIC's GOSUB. This gives the programmer three choices: inlining when time is a lot more important than memory subroutines when time is a little more important than memory functions when time is not more important than memory But subroutines look like a lot of trouble to implement, so before I even start thinking about it, I have to ask, is it worth it? Adam
cspw@alpha.cs.ru.ac.za (Peter Wentworth) (03/31/91)
In <1991Mar27.024602.21399@visix.com> adam@visix.com writes: >Given today's C compilers, is there any reason at all to explicitly >inline code with macros? >The only thing I could think of was there might be cases where you >want explicit control of the space/time tradeoff (but surely the >benefit is small). I find macros provide a level of abstraction that is often more flexible than using functions, and it does so at no cost. In pariticular, say I'm writing a program to manipulate Lisp-like cells, with three fields - a head, a tail, and a tag. I generally like the following ... #define head(p) p->head or head[p] or cells[p].head #define tail(p) p->tail or tail[p] or cells[p].tail #define tag(p) ... Now I can write tail(p) = head(tail(q)) Notice that I cannot use functions to generate L-values like this, and I have the freedom to change the data structure without having to change all my code. (I am a functional programmer at heart, so the notion that all accesses to "substructures" should have the same syntax, independent of whether they are arrays, records, pointers appeals to me. The fact that I can make all these accesses look like function calls appeals even more!) Pete -- EP Wentworth - Dept. of Computer Science - Rhodes University - Grahamstown. cspw@alpha.ru.ac.za