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