Path: utzoo!attcan!uunet!husc6!rutgers!rochester!pt.cs.cmu.edu!unh.cs.cmu.edu!agn
From: agn@unh.cs.cmu.edu (Andreas Nowatzyk)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <3683@pt.cs.cmu.edu>
Date: 25 Nov 88 16:51:31 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> <1309@cod.NOSC.MIL>
Organization: Carnegie-Mellon University, CS/RI
Lines: 59


>In article <2214@pt.cs.cmu.edu> mball@cod.NOSC.MIL (Michael S. Ball) writes:
> [regarding inlines with non-value returning function calls]
> 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.

It would help if you would read the article you are responding to. My
comments concerned a specific C++ compiler (ATT V1.2.1) and are quite
correct:

"foo.c", line 15: sorry, not implemented: non-value-returning inline bar() \
called in value-returning inline xyz::get()

No big deal really: just return some dummy and cfront is happy.

> [With regard to compiler decisions on when to inline]
> 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

I guess that is normally correct, but I had to resort to tricks to
get beyond some C++ language limitations. In the case at hand, a filter is
inserted between cfront and the C-compiler. This filter substitutes certain
code fragments in the inlined functions. One of the tasks is to insert
said line numbers, which are derived from the "#line" directives that CC
provides if run with the "-Fc" switch. Naturally inlining vs. function
calling changes the semantic dramatically. Not-inlining is an error here. 

Perhaps there are better ways to do this. How about a constructive
suggestion Mr. Ball? The problem is a simulator for a parallel architecture
that must be able to run of-the-shelf benchmarks. You are not allowed to
change these source codes. The result of a simulator run is an annotated
source code listing that states for each line how often it is executed, how
much CPU and how much memory-access time it took. To complicate matters a
bit, a few hundered copies are run concurrently and the entire process has
to complete in less than a CPU-day (a non-trivial contraint!).  CPU times
are computed from analyzing the assembly-output of the C-compiler and are
available to the C++ code through a filter operating on the assembly files
that leaves the number of clock cycles in certain places (results are
deterministic and don't depend on some hardware timer and/or system call).

I think this task could not be done with a smart all-in-one compiler:
is was absolutely necessary to add filters (small yacc/lex programs)
between cpp/cfront/cc/as.

> 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.

The point of this discussion is that I assert that macros are an indispensible
part of C++ and that inline functions - contrary to some claims - cannot
replace them. One important reason is that the programmer has little to no 
control over the expansion of inlines.

-- 
   --  Andreas Nowatzyk  (DC5ZV)

   Carnegie-Mellon University	     Arpa-net:   agn@unh.cs.cmu.edu
   Computer Science Department         Usenet:   ...!seismo!unh.cs.cmu.edu!agn
--