🚀 go-pugleaf

>|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..."