Michael Mair wrote:
Aloo wrote:
If we declare a recursive function as 'inline' then does it actually
convert to an iterative form during compilation ( the executable code
is iterative)?
The implementation/compiler has only to make the program behave
as if you have recursion. The inline keyword only is a recommendation
for the compiler but does not change the semantics.
Is it possible ?
Certainly. There may be cases where the compiler effectively makes
your program output the solution to a problem you tackled with a
lengthy program. As long as there is no visible difference, the
compiler may do pretty much everything, even that.
BTW: Code generators outputting C code often are in a better
position to recognize and optimize things like that than compilers.
Yes, but then you're presumably talking about code generators generating
from something that isn't C, which renders the issue moot.
I've seen C compilers that do, in fact, optimize certain tail-recursive
functions to iterative ones and can subsequently inline the result.
Doing it in all cases requires global code analysis and is unattractive
or unfeasible, depending on your platform. This is presumably where the
generators come in: if they generate all code, they could slip in such
analysis while they're at it.
This optimization tactic isn't widely seen in compilers because it's too
clever to pay off in practice; actual C code doesn't use tail-recursive
functions often (of the kind that readily admits optimization), if the
inlining is critical a programmer would never rely on a compiler's
ability to unfold tail recursion, and if the inlining is not critical,
who cares?
Compare this with Scheme compilers, which are *required* to optimize
tail recursion in all cases -- but then, this is because recursion is
the bread and butter of functional languages, and because such
optimization is actually feasible.
S.