[comp.lang.c++] why can't inline handle loops?

brian@uw-june.UUCP (Brian Bershad) (08/23/87)

I can understand the motivation (if it loops, it takes a while, so
why bother with inline expanding), but the restriction seems arbitrary.

Consider a spinlock for example:
	in the normal case, it returns immediately.  Only rarely will
	the lock be held and will spinning be required.

If it is an arbitrary restriction, what breaks if I take out the
check for looping in dcl3.c?



-- 
brian@june.cs.washington.edu                	Brian Bershad
{ihnp4,decvax,ucbvax}!uw-beaver!uw-june!brian   Dept. of Computer Science, FR-35
						University of Washington
                                                Seattle, WA 98195

jss@hector..UUCP (Jerry Schwarz) (08/24/87)

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