Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: in-line functions
Message-ID: <447@rlgvax.UUCP>
Date: Sat, 9-Feb-85 13:04:50 EST
Article-I.D.: rlgvax.447
Posted: Sat Feb  9 13:04:50 1985
Date-Received: Mon, 11-Feb-85 04:47:01 EST
References: <3100@umcp-cs.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 23

> jss@sjuvax (J. Shapiro) suggests that we consider inline functions,
> rather than ridiculously complex macros.  It's a good idea.  MESA has
> an INLINE keyword which does the obvious thing.  One could use
> ``register'' functions in C to do the same thing.

C++ has an "inline" keyword as well; I first saw the inline function idea
in the Mesa Reference Manual, and though it was a neat idea - I was glad
to see C++ picking it up.  (But wouldn't a "register" function be one that
was copied to the general registers and executed on a PDP-10? :-))

> One point (which is obvious when you think about it) is that the
> function definition must be available to all routines that use it; the
> straightforward approach of generating no code for a register function
> breaks the existing scope rules in C.  Two solutions come to mind:
> either put the definition in a header file (which might fail if
> compilers were allowed to ignore the register keyword when applied to
> functions)...

C++ takes this approach; since all C++ compilers support the "inline"
keyword, the problem you mention doesn't occur.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy