Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!ccncsu!ncr-fc!chuckp From: chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) Newsgroups: comp.lang.c Subject: Re: Were GNU C extensions proposed for the standard? Message-ID: Date: 24 Jan 90 16:48:28 GMT References: <153@dy4.UUCP> <2909@paperboy.OSF.ORG> Sender: news@ncr-fc.FtCollins.NCR.COM Organization: NCR Microelectronics, Ft. Collins, CO Lines: 28 In-reply-to: meissner@curley.osf.org's message of 22 Jan 90 15:36:57 GMT In article <2909@paperboy.OSF.ORG> meissner@curley.osf.org (Michael Meissner) writes: > | o the addition of the "inline" keyword > It was proposed, and rejected on the grounds of qualitity of > implementation (ie, the compiler should be smart enough to > figure out when to inline). Apples and oranges. What about "inline" keyword as a less kludgey alternative to macros? That is, the inline function would be in a _header_ file like a macro. The idea of the inline _keyword_, IMHO, is a macro-like facility that preserves the _semantics_ of C, _unlike cpp macros_. This is _not_ the same as automatically inlining small functions which, I agree, the compiler should do if optimization is enabled. I submit for discussion: Consider the difficulty of automatic inlining of separately compiled functions. I'm no compiler expert, but this _seems_ like an expensive optimization to implement. By having an inline (keyword) definition in the header file normally used when accessing the function (e.g. string.h), this type of optimization can be had much cheaper. Ideas? Opinions? -- Chuck Phillips -- chuckp%ncr-fc.FtCollins.NCR.COM uunet!ncr-sd!chuckp%ncr-fc ccncsu.ColoState.EDU!chuckp%ncr-fc