Michael Milgram writes:
> With reference to the original example, would the use of "CONTAINS"
> guarantee (within the standard) the (near) equivalent of
> inlining...
The standard does not mention the word inlining in *ANY* context. Nor
does it mention any similar words. Nor does it even hint about them.
Indeed the standard doesn't even use any form of the word compile
in normative text. A Fortran processor isn't guaranteed to even
*HAVE* a compiler; interpreted implementations are allowed. That is
a somewhat theoretical point - I don't know of any such
implementations (though I'm thinking that last time I said
something like that, someone might have pointed out the existence
of one somewhere at some time). I make such a theoretical point
just to illustrate how far the standard is from guaranteeing
anything like that - very far.
One can usefully make observations about how compilers typically
implement things. It tends to be hard to do useful work without
a certain degree of insight into such things. After all, even
talking about procedure call overhead inherently puts you into
such an area. But "typically" and "guaranteed" don't mean the
same thing, and I think it dangerous to confuse them.
I can't recall whether I made the point in this thread or one of the
other several on the same topic (between here and clf) in the past
week or so, but real compilers often generate procedure calls,
complete with argument passing, for ordinary code with no functions,
macros, or anything of the sort obvious to the user. To my knowledge
this is *ALWAYS* done for I/O. I know of no exceptions. It is
also sometimes done for other kinds of statements.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|