Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!labrea!rutgers!att!pegasus!ech
From: ech@pegasus.ATT.COM (Edward C Horvath)
Newsgroups: comp.lang.c++
Subject: Re: Inline functions
Message-ID: <2765@pegasus.ATT.COM>
Date: 7 Apr 89 14:56:34 GMT
References: <225@zeek.UUCP>
Organization: AT&T ISL Middletown NJ USA
Lines: 31

From article <225@zeek.UUCP>, by larry@zeek.UUCP (Larry Podmolik):
> I have a question concerning inline functions: where should they be
> placed?  I don't like putting the body of the function in the class
> declaration, since it makes the class "interface" harder to read,
> especially if you don't care HOW a routine is implemented.
 
> On page 266, Bjarne says:
 
> 	The _inline_ specifier is only a hint to the compiler,
> 	does not affect the meaning of the program, and may be
> 	ignored.

You over-interpreted bs's statement: the compiler may elect to compile a
genuine function for an inline, or may elect to expand the function call
into the function body.  However, the latter option is available ONLY if
the body of the function appears in the interface file, and cfront always
chooses the latter option...thus your inline functions are nil.

If you want a genuine function, move the body to the implementation (as you
have already done) and remove the inline keyword from the interface file.

Apparently you missed the point of inline: it is intended to replace the
baroque #define's used by many C programmers with a somewhat better-
behaved construct.  An inline-expanded function is faster (no argument
pushing, no stackframe buildup/teardown, no jsr/rts) but generally costs
more code space (every invocation becomes a copy of the body).

I hope that clears things up a bit.  The "unclean" appearance of a function
body in the interface file is properly regarded as a wart on the language.

=Ned Horvath=