Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!helios.ee.lbl.gov!nosc!cod!mball
From: mball@cod.NOSC.MIL (Michael S. Ball)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <1304@cod.NOSC.MIL>
Date: 22 Nov 88 04:32:59 GMT
References: <6590072@hplsla.HP.COM> <1757@dataio.Data-IO.COM> <3637@pt.cs.cmu.edu>
Reply-To: mball@cod.nosc.mil.UUCP (Michael S. Ball)
Organization: Naval Ocean Systems Center, San Diego
Lines: 82

In article <3637@pt.cs.cmu.edu> agn@unh.cs.cmu.edu (Andreas Nowatzyk) writes:
>Bjarne Strousrup's C++ book claims that inline functions
>eliminate the need for most uses of macros and other
>cpp-features. I find that statement overly optimistic and
>plain false in many actual cases. Using the ATT version 1.2.1
>of C++, I found inline functions to be inadequate because:
>
>a) They produce poor code: Everything becomes one large
>   comma-expression. Even optimized, the resulting assembly
>   code is awful.

You are confusing a language feature with an implementation.  If
a particular C compiler can't produce good code from comma expressions,
prehaps you should get a better one.  Better yet, look at some other
implementations of C++ and see what they do.  Cfront was the first
try at this, and is constrained by having to go through existing
C compilers.  There are limits to what you can do in that situation and
cfront does rather well.

>b) They lack control of temporary variables and/or objects.
>   Numerous temporary variables are being added - frequently
>   without need. Since my C-compiler doesn't optimize the use
>   of registers, it is not possible to force inline functions
>   to keep certain temporary variables in registers.

Try getting a better C compiler!

>c) They have a lot of restrictions (inability to use functions
>   that don't return values, no loops, troublesome nesting, etc.).

Huh!  I don't know what you mean by "troublesome nesting", but you can
certainly have inline functions without return values.  The decision not to
include looping constructs is reasonable, particularly for a compiler which
must produce C.  The contortions needed to include loops in a value
context give more overhead than a function call.  Also, if you have a loop,
the function call overhead is most likely a small percentage of running
time.  Yes, I know that sometimes the loop isn't executed very often, I'm
talking about the likely payback for the effort.

>d) They lack control of instantiation: 2 (identical) 
>   int inline function appear as the operands to an "==": the
>   left inlines normally, the right is replaced by a function call!

This is an implementation quirk of cfront.

>   In this case, replacing an inline with an function call is
>   fatal to the program (1), but the compiler doesn't even issue
>   a warning.

If replacing an inline function with a call is fatal you have a
programming error.  The "inline" declaration is simply a hint to
the compiler.  I see no need for a warning.  There are many situations
in which an inline function has to be instantiated.  For example,
when it is virtual and a pointer to it is needed for a virtual table.

>e) No reasonable substitute for conditional compilation: in some
>   modules certain functions have to be modified and parts of
>   the function would not compile in that environment.

But we were talking about replacing macros, not conditional compilation.

>The bottom line is - for now - that inline-function are not even
>close to replacing cpp. Note that performance is not the only reason:
>lacking control on when and how to expand can result in incorrect code.

Untrue.  If control of expansion matters the code was already incorrect.

>(1): In case you wondered how this can happen: the inline-function
>     needs to know the line-number of where it appears in the source code.
>     Is is part of an instrumentation package for parallel code running
>     on a simulated multiprocessor.

The only way an inline function can tell the line number at a call
is to pass the line number as a parameter to the function, in which
case it will work whether expanded or not.  Inline function processing is
done long after preprocessing, which is where the line number is known.

Michael S. Ball
TauMetric Corporation
1094 Cudahy Pl. Ste 302
San Diego, CA 92110
(619)275-6381