Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uakari.primate.wisc.edu!ames!elan!tom
From: tom@elan.elan.com (Tom Smith)
Newsgroups: comp.lang.c++
Subject: Re: inline policy
Message-ID: <661@elan.elan.com>
Date: 13 Nov 89 21:15:28 GMT
References: <10121@alice.UUCP>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 47

From article <10121@alice.UUCP>, by bs@alice.UUCP (Bjarne Stroustrup):
> On inlining:

[ discussion of inlining being an optimization with varied value removed ]

> Personally, I typically use inlining only for ``one liners'' where
> a function body is ``clearly'' shorter than the function call it
> would replace.

My most common use by far is "access functions", to provide read-only
access to private data members.

> Cfront will inline a function
> at most once in a single expression. The primary reason for this is to
> protect against recursion. A secondary reason is to allow different inlinings
> of a function in a block to share local temporary variables. The latter can
> be important on architectures with limited stack space.

This seems like a limiting and potentially damaging generalization.
Take the following illustration of an inline access-type member function:
    class Foo {
	int a;
    public:
	int A() const  { return a; }
    };

There is clearly (from the compiler's point of view) no danger of recursion
or side affects given the lack of local variables and the 'const' declaration
of the function itself.  If the above comment regarding inlining within
a statement is taken literally, the following results in a static "outlined"
copy of Foo::A():
    int b = foo.A() + foo.A() / 2;

After using C++ almost exclusively for 3 years on several large-scale
projects, I have found a major problem to be that of executable size.
The primary causes of an overly-large executable are either multiple
virtual function table instances (no longer a problem in cfront 2.0),
or gratuitous local function copies resulting from non-inlineable functions.
If cfront outlines a copy of Foo::A() in the statement above, without
issuing a warning, then it will be necessary for programmers using the
AT&T C++ implementation to examine the translated output of cfront
regularly for outlined functions, and to tune their source code in
non-intuitive ways merely to ensure adequate performance.

    Thomas Smith
    Elan Computer Group, Inc.
    tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom