Path: utzoo!attcan!uunet!tektronix!tekcrl!tekfdi!videovax!bart
From: bart@videovax.Tek.COM (Bart Massey)
Newsgroups: comp.lang.c++
Subject: Re: macros vs. inline functions
Message-ID: <5338@videovax.Tek.COM>
Date: 24 Nov 88 02:32:15 GMT
References: <6590072@hplsla.HP.COM> <1757@dataio.Data-IO.COM> <3637@pt.cs.cmu.edu> <1304@cod.NOSC.MIL> <3663@pt.cs.cmu.edu>
Reply-To: bart@videovax.UUCP (Bart Massey)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 21

In article <3663@pt.cs.cmu.edu> agn@unh.cs.cmu.edu (Andreas Nowatzyk) writes:
[ a bunch of reasons why inline functions are silly in cfront ]

I'm sure I won't be the first to point this out, but I don't think GCC/G++'s
inline functions have any of the problems you mentioned.  In fact, the code
produced by inline functions in this compiler is often better than you could
do with a macro.  This is because the compiled code is inlined, not the
source text. (Heck, you can even have inlines with *tail recursion* :-).

The problem, as a previous poster pointed out, is that inlines are badly
implemented in cfront.  Note, for example, that one could still generate C
code to implement an instantiation of an inline function which violates the
cfront restrictions (e.g. no loops, no void function calls) -- it just
wouldn't be representable as a comma expression, and thus the inline and the
surrounding output C code wouldn't necessarily look anything like the source.

I think I'll write a machine description for GCC which emits K&R C. 1/2 :-)

					Bart Massey
					..tektronix!videovax.tek.com!bart
					..tektronix!reed.bitnet!bart