Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!rutgers!sri-spam!ames!sdcsvax!ucbvax!ulysses!hector!jss
From: jss@hector..UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: why can't inline handle loops?
Message-ID: <2849@ulysses.homer.nj.att.com>
Date: Mon, 24-Aug-87 09:53:09 EDT
Article-I.D.: ulysses.2849
Posted: Mon Aug 24 09:53:09 1987
Date-Received: Tue, 25-Aug-87 02:53:31 EDT
References: <3004@uw-june.UUCP>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: jss@hector (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Lines: 18
Keywords: inline, loops

In article <3004@uw-june.UUCP> brian@uw-june.UUCP (Brian Bershad) writes:
>I can understand the motivation (if it loops, it takes a while, so
>why bother with inline expanding), but the restriction seems arbitrary.
>

The limitation is a implementation limitation, not a philisophical
one.  Since cfront uses C as an intermediate language, in order to
"inline" a function it must create an equivalent C expression.  No C
expressions (except function calls) contain loops.

There are other circumstances in which cfront can't find an
equivalent expression and generates a function call even when the
function is declared "inline".  In doubtful cases (and most are) I
always examine the -F output of critical functions to be sure that
inlining has been successful.  Sometimes it is neccessary to change
the body of the function declared inline to get good code.

Jerry Schwarz