在您否决或开始说goto邪恶和过时之前，请阅读在这种情况下为什么可行的理由。在将其标记为重复项之前，请阅读完整的问题。
当I stumbled across computed gotos时，我正在阅读有关虚拟机解释器的信息。显然，它们可以显着提高某些代码的性能。最著名的示例是主VM解释器循环。
考虑这样的（非常）简单的VM：
#include <iostream>
enum class Opcode
{
HALT,INC,DEC,BIT_LEFT,BIT_RIGHT,RET
};
int main()
{
Opcode program[] = { // an example program that returns 10
Opcode::INC,Opcode::BIT_LEFT,Opcode::INC,Opcode::RET
};
int result = 0;
for (Opcode instruction : program)
{
switch (instruction)
{
case Opcode::HALT:
break;
case Opcode::INC:
++result;
break;
case Opcode::DEC:
--result;
break;
case Opcode::BIT_LEFT:
result <<= 1;
break;
case Opcode::BIT_RIGHT:
result >>= 1;
break;
case Opcode::RET:
std::cout << result;
return 0;
}
}
}
该VM所能做的就是对几种类型int进行一些简单的操作并将其打印出来。尽管它的有用性令人怀疑，但仍然可以说明该主题。
VM的关键部分显然是switch循环中的for语句。它的性能取决于许多因素，其中最重要的因素当然是branch prediction，而跳转到适当执行点的动作（case标签）。
这里有优化的空间。为了加快执行此循环的速度，可以使用所谓的 compute gotos 。
计算的Gotos
计算的goto是Fortran程序员和使用某些（非标准）GCC扩展的程序员所熟知的结构。我不赞成使用任何非标准的，实现定义的和（显然）未定义的行为。但是，为了说明问题的概念，我将使用提到的GCC扩展的语法。
在标准C ++中，我们允许定义标签，以后可以通过goto语句跳转到这些标签：
goto some_label;
some_label:
do_something();
这样做不被认为是好的代码（and for a good reason!）。尽管有很多反对使用goto的理由（其中大多数与代码的可维护性有关），但对于这种可憎的功能还是有一个应用程序。这是性能的提高。
Using a goto statement can be faster than a function invocation.这是因为调用函数时必须完成“文书工作”，例如设置堆栈和返回值。同时，goto有时可以转换为单个jmp汇编指令。
为充分发挥goto的潜力，对GCC编译器进行了扩展，使goto更具动态性。也就是说，可以在运行时确定要跳转到的标签。
此扩展名允许获取标签指针，类似于函数指针并对其进行goto寻址：
void* label_ptr = &&some_label;
goto (*label_ptr);
some_label:
do_something();
这是一个有趣的概念，可让我们进一步增强我们的简单VM。而不是使用switch语句，我们将使用标签指针数组（即所谓的 jump table ），然后使用goto指向相应的指针（操作码将用于对数组进行索引）：
// [Courtesy of Eli Bendersky][4]
// This code is licensed with the [Unlicense][5]
int interp_cgoto(unsigned char* code,int initval) {
/* The indices of labels in the dispatch_table are the relevant opcodes
*/
static void* dispatch_table[] = {
&&do_halt,&&do_inc,&&do_dec,&&do_mul2,&&do_div2,&&do_add7,&&do_neg};
#define DISPATCH() goto *dispatch_table[code[pc++]]
int pc = 0;
int val = initval;
DISPATCH();
while (1) {
do_halt:
return val;
do_inc:
val++;
DISPATCH();
do_dec:
val--;
DISPATCH();
do_mul2:
val *= 2;
DISPATCH();
do_div2:
val /= 2;
DISPATCH();
do_add7:
val += 7;
DISPATCH();
do_neg:
val = -val;
DISPATCH();
}
}
此版本比使用switch的版本（链接的博客文章中的版本，而不是上面的版本）快25％。这是因为每次操作后仅执行一次跳转，而不是两次。
使用 switch的控制流：
Opcode::FOO然后执行Opcode::SOMETHING，它将看起来像这样：
switch代码，第二个返回到实际指令。
相反，如果我们要使用一组标签指针（提醒一下，它们是非标准的），则只会有一个跳转：
值得注意的是，除了通过减少操作来节省周期外，我们还通过消除额外的跳跃来提高分支预测的质量。
现在，我们知道通过使用标签指针数组而不是switch，我们可以显着提高VM的性能（大约20％）。我想也许它也可以有其他一些应用程序。
我得出的结论是，这种技术可以在任何具有循环的程序中使用，在该循环中，它依次间接地调度一些逻辑。一个简单的示例（除了VM）可能是在多态对象容器的每个元素上调用virtual方法：
std::vector<Base*> objects;
objects = get_objects();
for (auto object : objects)
{
object->foo();
}
现在，这有更多的应用程序。
但是有一个问题：在标准C ++中没有诸如标签指针之类的东西。因此，问题是：有没有办法在标准C ++ 中模拟可以计算的goto的行为，使其性能相匹配？。
编辑1：
使用开关还有另一个缺点。 user1937198让我想起了它。它是绑定检查。简而言之，它将检查switch内部的变量值是否与任何case相匹配。它添加了冗余分支（此检查是标准要求的）。
编辑2：
In response to cmaster，我将阐明减少虚拟函数调用开销的想法。一种肮脏的方法是在每个派生实例中都有一个代表其类型的ID，该ID将用于索引跳转表（标签指针数组）。问题是：
- 没有跳转表是标准的C ++
- 添加新的派生类时，需要修改所有跳转表。
如果有人提出了某种模板魔术（或者万不得已的宏），我将很感激，这样可以使其更加简洁，可扩展和自动化，如下所示：