Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Why doesn't inline always work?
Keywords: inline fails
Message-ID: <10557@alice.UUCP>
Date: 9 Mar 90 06:30:43 GMT
References: <540@janus.Quotron.com> <5041@odin.SGI.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 33

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