> Functions are great for making written code (C, C++, etc.) mode> readable and structured, however, they do not seem to make much sense> when you get down to the raw machine code which actually is executed> by a processor.

There is still one purpose for retaining this structure in the
executable. I'll get to this below.

> The output of such a compiler would be larger binary files (since> every call to a function would expand to the entire function body)> however the execution time for such a program should be improved> (relative to a non-inlining compiler) by a factor proportional to the> number of function calls in the program.

I remember reading somewhere that, in fact, by inlining functions like
this, the potential for optimisations is greater. My intuition can
see why. But code bloat would still be significant.

> Perhaps compilers already take advantage of the idea I have outlined or> perhaps there are some problems with the idea which I don't know about> (an old C++ book I have says, "Compiler limits prevent complicated> functions from being inlined," but no further explanation is given.

In my opinion, the major drawback to inline functions is that they are
much harder to debug. Suppose you have code which frequently calls:

my_sqrt(..)

And you suspect a bug in your square root function. If my_sqrt() were
inlined at every point that it was used, it would be impossible to set
a breakpoint at the start of my_sqrt() and to examine an invocation of
this function. It becomes a real headache.

Furthermore, it helps a great deal to know the calling sequence at
runtime in case, say, an assertion fails and you need to know how your
function was called and what the arguments were.

---
Ben Elliston
bje@cygnus.com
[That's not a very persuasive argument. There's no reason the debugger
can't know all the places the inline function was called and put breakpoints
on all of them. It has to do something similar in compilers that unwind
loops already. -John]