Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: inline & Zortech compiler
Message-ID: <1911@dataio.Data-IO.COM>
Date: 24 Mar 89 19:05:46 GMT
References: <42890@clyde.ATT.COM>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Distribution: na
Organization: Data I/O Corporation; Redmond, WA
Lines: 36

In article <42890@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes:
>Anyhow, in several of my attempts to uncover cases when
>the compiler does not properly handle inline, I have
>not found any.  Has anyone found circumstances where the 
>inline reserved word is used, the Zortech compiler will not
>generate inline function code?

The compiler will generate a real function call, rather than inline
expanding an inline function, in the following cases:
1. Calling it through a pointer-to-inline-function.
2. If the body of the function contains if, goto, do, for, while or
   switch statements.
3. If the inline function is variadic.
4. If the inline function is declared, but not defined yet, at the
   point of its use.
It's my understanding that the only difference between this behavior and
cfront's is that cfront is able to inline expand *some* functions containing
if statements. It does this by replacing them with ?: expressions.

It's quite difficult to inline expand a switch or loop statement, and the
utility of it is poor, so it's not done. (The purpose of inlining is to
gain speed, and for a loop most of the time is presumably in the loop, not
in the function call.)

There is nothing in the language definition to either require or disallow
inline function expansion. It is purely a 'quality of implementation' issue.
The only requirement is that the behavior of the program is *as if* they
were all regular functions. Inline is merely a hint to the compiler.

One problem with inlines: doing them is so easy and seductive that many
programmers go overboard with them, generating far more than would yield
a real improvement. The resulting problems are:
1. The program may wind up being unnecessarilly large.
2. Keeping all those functions in the compiler's symbol table chews up
   lots of memory. On a 640k PC, this is frequently the cause of running
   the compiler out of memory.