Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!ksand From: ksand@Apple.COM (Kent Sandvik) Newsgroups: comp.std.c++ Subject: Re: Pre-proposal: ~const [Rev 1.6] Message-ID: <47849@apple.Apple.COM> Date: 8 Jan 91 03:22:05 GMT References: <60083@microsoft.UUCP> <60331@microsoft.UUCP> Distribution: comp Organization: Apple Computer Inc., Cupertino, CA Lines: 34 >|On 27 Dec 90 19:56:22 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said: >|Let me home in on this. One problem of the current definition of >|'inline' is that it specifies that every time the given function is >|called, it should be inlined. In other words, 'inline' currently means >|'can inline, *must* inline'. The problem I see with this is that, for >|one of the two common reasons one wants to inline, in many cases >|expanding inline a function is irrelevant -- it is only productive in a >|few places, e.g. in inner loops, or where substantial opportunities for >|code merging exist. Inlining a function everywhere, unless it is very >|small, is just going to increase size with little benefit in speed. The danger with inlines and compiler optimization is not very high, mostly because non-inlined code suffers mostly concerning performance. A keyword like volatile in ANSI C is far more dangerous, because assumptions of register use could cause a lot of breakable, unportable code. So if a compiler does not do inline will not break code, but if the compiler does not follow the volatile keywords, then it would cause a lot of register-dependent code to fail. I hope standards creators take things like this into account concerning 'hint' keywords. Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."