Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!think!yale!cmcl2!stealth.acf.nyu.edu!brnstnd From: brnstnd@stealth.acf.nyu.edu Newsgroups: comp.lang.c Subject: Re: Were GNU C extensions proposed for the standard? Message-ID: <13716@stealth.acf.nyu.edu> Date: 24 Jan 90 22:24:42 GMT References: <153@dy4.UUCP> <2909@paperboy.OSF.ORG> Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein) Distribution: usa Organization: IR Lines: 14 In article chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) writes: > 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. Correct. It's simply impossible to do that inlining under the current compile-link model, and worse than impossible for the compiler to figure out when that inlining should happen. (After all, there's no excuse for the compiler to look at the code in another file, and the linker can't perform this optimization.) GNU did a good job with inline. ---Dan