Re: Should Inline be private in the private part of a package spec?

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:613764f5-0216-4271-9278-70290198d71d@googlegroups.com...
> On Thursday, August 9, 2012 4:18:40 PM UTC-6, Randy Brukardt wrote:
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>>
>> If 10.1.4(7/3) didn't exist, then Inline would not need to be given in
>> visible spec. But as I noted elsewhere, I don't think Inline should be 
>> given
>> anywhere -- compilers can figure out when to Inline better than any human
>> can. Hints about the amount of space expansion allowed for the entire
>> program and the relative importance of particular subprograms would be 
>> much
>> more valuable.
>
> Well, isn't that the reason that Pragma Inline allows the compiler to 
> inline the
> subprogram, rather than being a compiler switch _requiring_ the subprogram 
> to be inlined?

Sure. But nothing prevents a compiler from inlining any subprogram it wants. 
And if it can, it ought to inline every subprogram that makes sense.

So the only real advantages of Inline are
(1) Adding a compilation dependence, which makes it easier to implement on 
most compilers;
(2) Providing a rather non-specific hint that it might be a good idea to 
inline this subprogram.

I'd rather have a more specific hint, and let the compiler decide how best 
to implement it. (And get rid of the compiler dependence -- nothing good 
comes out of extra dependences.) In particular, some subprogram might be 
best partially inlined (that is, substituting some but not all parameters in 
a duplicate of the subprogram). For example, imagine New_Line, where the 
second parameter is rarely used. And on some machines, a call is going to be 
no more expensive than the inlined code (in which case the call is preferred 
because it could decrease cache pressure). And so on...

                                         Randy.