[comp.lang.c++] Why doesn't inline always work?

todd@janus.Quotron.com (Todd Booth) (03/08/90)

I know of a 2.0 C++ beta product that does not expand inline
functions that contain a goto, for, do, or while, as inline.  

Do any other C++ products?  

Can anyone think of a technical reason not to (assuming the
programmer knows what s/he is doing?

--todd booth / Quotron

shap@delrey.sgi.com (Jonathan Shapiro) (03/09/90)

In article <540@janus.Quotron.com> todd@janus.Quotron.com (Todd Booth) writes:
>I know of a 2.0 C++ beta product that does not expand inline
>functions that contain a goto, for, do, or while, as inline.  
>
>Do any other C++ products?  
>
>--todd booth / Quotron

All cfront-based C++ systems have this limitation.

The problem is that in order to perform inlining, cfront turns the
function into a single expression (remember that the function needs to
return a result, so it needs to be an expression).

Since C has no notion of returning a value from a block, and goto is
not legal within an expression, cfront has no way to generate inline
loops.

This is one of the areas in which generating object code would be a
big win.

Jonathan Shapiro
Silicon Graphics, Inc.

ark@alice.UUCP (Andrew Koenig) (03/09/90)

In article <5041@odin.SGI.COM>, shap@delrey.sgi.com (Jonathan Shapiro) writes:

> The problem is that in order to perform inlining, cfront turns the
> function into a single expression (remember that the function needs to
> return a result, so it needs to be an expression).

> Since C has no notion of returning a value from a block, and goto is
> not legal within an expression, cfront has no way to generate inline
> loops.

> This is one of the areas in which generating object code would be a
> big win.

Not true.

Imagine an `extended C' in which expressions can have loops,
gotos, even blocks embedded within them.  There is nothing
conceptually difficult about translating extended C into
plain C.  It is certainly no harder than translating it into
machine language.

The general strategy is to take subexpressions with loops
and the like and split them out into separate statements
that assign the results of these subexpressions to temporaries.
Then take the main expression and rewrite it in terms of these
temporaries.

The overall process is rather messy in practice but there's
nothing particularly profound about it.  The only reason we
haven't done it is lack of time.
-- 
				--Andrew Koenig
				  ark@europa.att.com

bright@Data-IO.COM (Walter Bright) (03/10/90)

In article <540@janus.Quotron.com> todd@janus.Quotron.com (Todd Booth) writes:
<I know of a 2.0 C++ beta product that does not expand inline
<functions that contain a goto, for, do, or while, as inline.  
<Do any other C++ products?
	No.
<Can anyone think of a technical reason not to (assuming the
<programmer knows what s/he is doing?

Because of the following circumstance:

	inline int func()
	{	int i;
		for (i = 0; i < 10; i++)
			g();
		return i;
	}

Now, suppose it appears in:

	foo(a || (c += (g(),func()) + g()) || baz);

Try to inline-expand this, preserving the semantics.

C++ compilers inline-expand functions by substituting expressions.
for, switch, while etc. do not map into C expressions.
If's can usually be converted into an equivalent C expression
using &&, || or ?:.

Some significant gymnastics would be required to solve this problem
in the general case, and most implementors (I presume) feel that the
gain to the user is not worth the implementation effort, complexity
and bugs. There's a long list of other things that have higher
priority (such as more efficient code generation).

saustin@bbn.com (03/10/90)

bright@Data-IO.COM (Walter Bright) writes:

>In article <540@janus.Quotron.com> todd@janus.Quotron.com (Todd Booth) writes:
><I know of a 2.0 C++ beta product that does not expand inline
><functions that contain a goto, for, do, or while, as inline.  
><Do any other C++ products?
>	No.

Yes. GNU g++ does!

>C++ compilers inline-expand functions by substituting expressions.

As far as I can gather, g++ plonks the machine instructions wherever the
inline function was mentionned. It is not constrained to substitite a valid
C expression for the function call.

I should think that cfront could be modified to behave correctly by writing
loads of "if" statements, in which case there would be a near one-to-one
correspondence between the flow of the C and and the resulting assembler
output.

	Steve Austin