Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!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: <1309@cod.NOSC.MIL>
Date: 24 Nov 88 03:14:46 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: mball@cod.nosc.mil.UUCP (Michael S. Ball)
Organization: Naval Ocean Systems Center, San Diego
Lines: 57

In article <3663@pt.cs.cmu.edu> agn@unh.cs.cmu.edu (Andreas Nowatzyk) writes:
>
>In article <2191@pt.cs.cmu.edu> mball@cod.NOSC.MIL (Michael S. Ball) writes:
>> ... If
>> a particular C compiler can't produce good code from comma expressions,
>>
>Sure: get a better compiler is the universal answer. Unfortunately that
>isn't a viable option in many cases (like in this one).
>The point is: a macro gives you more controll over what is going on,
>inline functions don't and there are cases where you need precise control.

When we talk about eliminating macros we are talking about LANGUAGE, not
some deficient implementation which you (and far too many others) are
required to use.  Sure, some compilers may be so bad you need "asm"
inserts to replace arithmetic expressions, but that doesn't mean that
there are flaws in idea of expressions.  If you need that precise "control"
use macros, but don't be surprised when the compiler generates bad code
for them too.

>> 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
>Inline functions cannot use functions that have no return-value (a
>side-effect of using comma-expressions).

This is absolutely incorrect.  We do it all the time and they work just fine.
I suspect you are seeing some other effect and confusing causes.

>Inline functions calling other
>inline function sometimes inline, somethimes thay don't. Exactly when
>each case happens is rather arbitrary.

Not arbitrary, just unknown to you, and possibly different in different
implementation.  It is a decision the compiler makes, not the programmer,
and can have no effect on the semantics.  Our own compiler has no such
limits at all.  I don't know the details of the cfront algorithm, but
the only time I have seen it happen for recursive functions, where
the expansion must stop somewhere.

>>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.
>Not so fast: the problem is instrument a piece of code whitout changeing
>it. Whenever that application code is dealing with the simulated environment,
>the simulator need to know about it. It is possible to do that in C++,
>but the details are quite messy and involve operator overloading, the
>use of non-trivial macros and some other stuff.

This does not change the point, which is that inline function expansion/
non-expansion cannot change the semantics of the call.  It is not affected
by the environment of the calling location except for values passed as
parameters.  Your statement about requiring expansion to work properly 
simply demonstrates a lack of understanding of the definition of inline
functions, which are NOT in any sense macros.

Michael S. Ball
TauMetric Corporation