blocks|key|3161312|text|当前所有主流编译器都能很好地执行尾部调用优化(并且已经做了十多年了)，even+for+mutually+recursive+calls例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3161313|int+bar(int,+int);

int+foo(int+n,+int+acc)+{
++++return+(n+==+0)+?+acc+:+bar(n+-+1,+acc+%2B+2);
}

int+bar(int+n,+int+acc)+{
++++return+(n+==+0)+?+acc+:+foo(n+-+1,+acc+%2B+1);
}|code-block|syntax|javascript|3161314|让编译器进行优化很简单:只需打开优化以提高速度：|3161315|用于MSVC的|3161316|，使用/O2或/Ox.|unordered-list-item|style|CODE|3161317|For，使用-O3|3161318|3161319|检查编译器是否进行了优化的一种简单方法是执行调用，否则会导致堆栈溢出-或者查看汇编输出。|3161320|作为一个有趣的历史注释，在Mark+Probst的diploma+thesis课程中，对C语言的尾部调用优化被添加到了GCC中。本文描述了实现过程中一些有趣的注意事项。这本书值得一读。|3161321|entityMap|0|LINK|mutability|MUTABLE|url|https://godbolt.org/g/TjqTHV|1|http://www.complang.tuwien.ac.at/schani/diplarb.ps^0|Z|X|0|0|0|0|0|3|3|7|3|0|6|3|0|0|0|P|E|1|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1D|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|1E|8|@]|9|@]|C|$]]|$1|M|3|N|5|O|7|1F|8|@$A|1G|B|1H|P|Q]|$A|1I|B|1J|P|Q]]|9|@]|C|$]]|$1|R|3|S|5|O|7|1K|8|@$A|1L|B|1M|P|Q]]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1O|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]|$1|Y|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]|16|$5|11|12|13|C|$14|17]]]]

All current mainstream compilers perform tail call optimisation fairly well (and have done for more than a decade), <a href="https://godbolt.org/g/TjqTHV" rel="noreferrer">even for mutually recursive calls</a> such as:

<pre><code>int bar(int, int);

int foo(int n, int acc) {
 return (n == 0) ? acc : bar(n - 1, acc + 2);
}

int bar(int n, int acc) {
 return (n == 0) ? acc : foo(n - 1, acc + 1);
}
</code></pre>

Letting the compiler do the optimisation is straightforward: Just switch on optimisation for speed:

<ul>
<li>For MSVC, use <code>/O2</code> or <code>/Ox</code>.</li>
<li>For GCC, Clang and ICC, use <code>-O3</code></li>
</ul>

An easy way to check if the compiler did the optimisation is to perform a call that would otherwise result in a stack overflow — or looking at the assembly output.

As an interesting historical note, tail call optimisation for C was added to the GCC in the course of a <a href="http://www.complang.tuwien.ac.at/schani/diplarb.ps" rel="noreferrer">diploma thesis</a> by Mark Probst. The thesis describes some interesting caveats in the implementation. It's worth reading.

blocks|key|366490|text|大多数编译器在调试版本中不会做任何类型的优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|366491|如果使用VC，尝试使用PDB信息打开的发布版本-这将允许您跟踪优化的应用程序，然后您应该有希望看到您想要的。然而，请注意，调试和跟踪优化的构建会让你到处跑，而且通常你不能直接检查变量，因为它们只会在寄存器中结束或被完全优化。这是一次“有趣”的经历。|366492|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most compilers don't do any kind of optimisation in a debug build.

If using VC, try a release build with PDB info turned on - this will let you trace through the optimised app and you should hopefully see what you want then. Note, however, that debugging and tracing an optimised build will jump you around all over the place, and often you cannot inspect variables directly as they only ever end up in registers or get optimised away entirely. It's an "interesting" experience...

blocks|key|366502|text|正如Greg提到的，编译器在调试模式下不会这样做。调试构建比prod构建慢是可以的，但它们不应该更频繁地崩溃:如果您依赖于尾部调用优化，它们可能就是这样做的。正因为如此，最好将尾部调用重写为普通循环。:-(|type|unstyled|depth|inlineStyleRanges|entityRanges|data|366503|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As Greg mentions, compilers won't do it in debug mode. It's ok for debug builds to be slower than a prod build, but they shouldn't crash more often: and if you depend on a tail call optimization, they may do exactly that. Because of this it is often best to rewrite the tail call as an normal loop. :-(

blocks|key|3161376|text|gcc+4.3.2完全内联了这个函数(糟糕/琐碎的atoi()实现)到main()中。优化级别为-O1。我注意到，如果我尝试使用它(即使将它从static改为extern，尾递归也会很快消失，所以我不会依赖它来保证程序的正确性。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3161377|#include+<stdio.h>
static+int+atoi(const+char+*str,+int+n)
{
++++if+(str+==+0+%7C%7C+*str+==+0)
++++++++return+n;
++++return+atoi(str%2B1,+n*10+%2B+*str-'0');
}
int+main(int+argc,+char+**argv)
{
++++for+(int+i+=+1;+i+!=+argc;+%2B%2Bi)
++++++++printf("%25s+->+%25d\n",+argv[i],+atoi(argv[i],+0));
++++return+0;
}|code-block|syntax|javascript|3161378|entityMap^0|P|6|Z|6|1C|3|1Z|6|27|6|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|L|$]]

gcc 4.3.2 completely inlines this function (crappy/trivial <code>atoi()</code> implementation) into <code>main()</code>. Optimization level is <code>-O1</code>. I notice if I play around with it (even changing it from <code>static</code> to <code>extern</code>, the tail recursion goes away pretty fast, so I wouldn't depend on it for program correctness.

<pre><code>#include &lt;stdio.h&gt;
static int atoi(const char *str, int n)
{
 if (str == 0 || *str == 0)
 return n;
 return atoi(str+1, n*10 + *str-'0');
}
int main(int argc, char **argv)
{
 for (int i = 1; i != argc; ++i)
 printf("%s -&gt; %d\n", argv[i], atoi(argv[i], 0));
 return 0;
}
</code></pre>

blocks|key|366221|text|除了显而易见的(编译器不会做这种优化，除非你要求)，C%2B%2B中的尾部调用优化也有一个复杂性:析构函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|366222|假设如下所示：|366223|+++int+fn(int+j,+int+i)
+++{
++++++if+(i+<=+0)+return+j;
++++++Funky+cls(j,i);
++++++return+fn(j,+i-1);
+++}|code-block|syntax|javascript|366224|编译器不能(通常)对此进行尾调用优化，因为它需要在递归调用返回后调用cls的析构函数。|offset|length|style|CODE|366225|有时编译器可以看到析构函数没有外部可见的副作用(所以它可以提前完成)，但通常不能。|366226|一种特别常见的形式是Funky实际上是一个std::vector或类似的东西。|366227|entityMap^0|0|0|0|Y|3|0|0|A|5|L|B|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@$K|Y|L|Z|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@$K|12|L|13|M|N]|$K|14|L|15|M|N]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|T|$]]

As well as the obvious (compilers don't do this sort of optimization unless you ask for it), there is a complexity about tail-call optimization in C++: destructors.

Given something like:

<pre><code> int fn(int j, int i)
 {
 if (i &lt;= 0) return j;
 Funky cls(j,i);
 return fn(j, i-1);
 }
</code></pre>

The compiler can't (in general) tail-call optimize this because it needs
to call the destructor of <code>cls</code> after the recursive call returns.

Sometimes the compiler can see that the destructor has no externally visible side effects (so it can be done early), but often it can't.

A particularly common form of this is where <code>Funky</code> is actually a <code>std::vector</code> or similar.

It seems to me that it would work perfectly well to do tail-recursion optimization in both C and C++, yet while debugging I never seem to see a frame stack that indicates this optimization. That is kind of good, because the stack tells me how deep the recursion is. However, the optimization would be kind of nice as well.

Do any C++ compilers do this optimization? Why? Why not?

How do I go about telling the compiler to do it?

<ul>
<li>For MSVC: <code>/O2</code> or <code>/Ox</code></li>
<li>For GCC: <code>-O2</code> or <code>-O3</code></li>
</ul>

How about checking if the compiler has done this in a certain case?

<ul>
<li>For MSVC, enable PDB output to be able to trace the code, then inspect the code</li>
<li>For GCC..?</li>
</ul>

I'd still take suggestions for how to determine if a certain function is optimized like this by the compiler (even though I find it reassuring that Konrad tells me to assume it)

It is always possible to check if the compiler does this at all by making an infinite recursion and checking if it results in an infinite loop or a stack overflow (I did this with GCC and found out that <code>-O2</code> is sufficient), but I want to be able to check a certain function that I know will terminate anyway. I'd love to have an easy way of checking this :)

<hr>

After some testing, I discovered that destructors ruin the possibility of making this optimization. It can sometimes be worth it to change the scoping of certain variables and temporaries to make sure they go out of scope before the return-statement starts.

If any destructor needs to be run after the tail-call, the tail-call optimization can not be done.

Which, if any, C++ compilers do tail-recursion optimization?

编译器

在我看来，在C和C++中同时进行尾递归优化会非常好，但在调试过程中，我似乎从来没有看到一个框架堆栈来表示这种优化。这很好，因为堆栈告诉我递归有多深。然而，优化也是很好的。有没有C++编译器做过这样的优化？为什么？为什么不行？我该如何告诉编译器这样做呢？微软-O3的：/O2或 GCC：-O2或MSVC如何检查编译器在特定...

问哪些C++编译器会进行尾递归优化？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪些C++编译器会进行尾递归优化？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪些C++编译器会进行尾递归优化？
EN