GOTO 仍然被视为有害吗？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

9 年前已关闭。

Answer 1

现代 GOTO 的一种用法是由 C# 编译器为由收益返回定义的枚举器创建状态机。

GOTO 应该由编译器而不是程序员使用。

Answer 2

我避免使用它，因为同事/经理无疑会在代码审查中或偶然发现它时质疑它的使用。 虽然我认为它有用途（例如错误处理情况），但您会与其他遇到某种问题的开发人员发生冲突。

这不值得。

Answer 3

几乎在所有可以使用 goto 的情况下，您都可以使用其他构造来执行相同的操作。 无论如何，编译器都会使用 Goto。

我个人从不明确使用它，也不需要。

Answer 4

您可以使用它来打破深度嵌套循环，但大多数时候您的代码可以重构为更干净，而无需深度嵌套循环。

Answer 5

我的一位同事说，使用 GOTO 的唯一原因是，如果你将自己编程到了一个角落，这是唯一的出路。 换句话说，提前正确设计，以后就不需要使用 GOTO。

我认为这部漫画完美地说明了“我可以重组程序的流程，或者使用一个小‘GOTO’来代替。” 当设计薄弱时，GOTO 是一种薄弱的出路。 迅猛龙捕食弱者。

Answer 6

Donald E. Knuth 在《文学编程》一书中回答了这个问题，1992 年 CSLI。 上页。 17 有一篇文章“使用 goto 语句进行结构化编程 “（PDF）。 我认为这篇文章也可能发表在其他书中。

文章描述了 Dijkstra 的建议并描述了该建议有效的情况。 但他还给出了许多反例（问题和算法），仅使用结构化循环无法轻松重现这些反例。

这篇文章包含了问题的完整描述、历史、例子和反例。

Answer 7

在 C 中，goto 仅在当前函数的范围内工作，这往往会本地化任何潜在的错误。 setjmp 和 longjmp 危险得多，它们是非本地的、复杂的并且依赖于实现。 然而在实践中，它们太晦涩和不常见，不会引起很多问题。

我认为 C 语言中 goto 的危险被过分夸大了。 请记住，最初的 goto 参数出现在老式 BASIC 等语言时代，初学者会编写如下所示的意大利面条代码：

3420 IF A > 2 THEN GOTO 1430

这里 Linus 描述了 goto 的适当用法>: http://www.kernel.org/doc/Documentation/CodingStyle（章节7).

Answer 8

在某些情况下，Go To 可以提供一种“真正的”异常处理的替代方法。 考虑一下：

ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;

显然，这段代码经过了简化，占用了更少的空间，所以不要太在意细节。 但考虑一下我在生产代码中多次看到的另一种选择，编码人员为了避免使用 goto 而采取了荒谬的长度：

success=false;
do {
    ptr = malloc(size);
    if (!ptr) break;
    bytes_in = read(f_in,ptr,size);
    if (count=<0) break;
    bytes_out = write(f_out,ptr,bytes_in);
    if (bytes_out != bytes_in) break;
    success = true;
} while (false);

现在从功能上讲，这段代码做了完全相同的事情。 事实上，编译器生成的代码几乎是相同的。 然而，在程序员热衷于安抚Nogoto（可怕的学术斥责之神）的过程中，这位程序员完全打破了while循环所代表的底层习惯用法，并做了真正的代码可读性的数字。 这并没有更好。

所以，这个故事的寓意是，如果您发现自己为了避免使用 goto 而采取了一些非常愚蠢的做法，那就不要这样做。

Answer 9

被 Jay Ballou 添加答案所吸引，我将添加 0.02 英镑。 如果 Bruno Ranschaert 还没有这样做，我会提到 Knuth 的“使用 GOTO 语句进行结构化编程”文章。

我没有看到讨论的一件事是 Fortran 教科书上教授的那种代码，虽然并不常见，但却是这样的。 例如 DO 循环的扩展范围和开放编码的子例程（请记住，这将是 Fortran II、Fortran IV 或 Fortran 66 - 而不是 Fortran 77 或 90）。 至少有可能语法细节不准确，但概念应该足够准确。 每种情况下的片段都位于单个函数内。

请注意，优秀但已过时（且已绝版）的书“编程风格的元素，第二Edn'，作者：Kernighan & Plauger 列举了当时（70 年代末）编程教科书中一些滥用 GOTO 的现实例子。 然而，下面的材料并非来自该书。

DO 循环的扩展范围

       do 10 i = 1,30
           ...blah...
           ...blah...
           if (k.gt.4) goto 37
91         ...blah...
           ...blah...
10     continue
       ...blah...
       return
37     ...some computation...
       goto 91

造成这种废话的原因之一是老式的打孔卡。 您可能会注意到，标签（完全不按顺序排列，因为这是规范风格！）位于第 1 列（实际上，它们必须位于第 1-5 列），代码位于第 7-72 列（第 6 列是延续）标记列）。 第 73-80 列将被赋予一个序列号，并且有机器可以将打孔卡组按序列号顺序进行排序。 如果您的程序位于已排序的卡片上，并且需要在循环中间添加一些卡片（行），则必须在这些额外的行之后重新打孔所有内容。 但是，如果您用 GOTO 内容替换一张卡片，则可以避免对所有卡片重新排序 - 您只需将新卡片用新的序列号塞到例程末尾即可。 可以将其视为“绿色计算”的首次尝试 - 节省打孔卡（或者更具体地说，节省重新打字的劳动力 - 以及节省随之而来的重新键入错误）。

哦，你可能还注意到我在作弊，而不是大喊大叫——Fortran IV 通常都是用大写字母编写的。

开放编码子例程

       ...blah...
       i = 1
       goto 76
123    ...blah...
       ...blah...
       i = 2
       goto 76
79     ...blah...
       ...blah...
       goto 54
       ...blah...
12     continue
       return
76     ...calculate something...
       ...blah...
       goto (123, 79) i
54     ...more calculation...
       goto 12

标签 76 和 54 之间的 GOTO 是计算 goto 的一个版本。 如果变量 i 的值为 1，则转到列表中的第一个标签 (123)； 如果它的值为 2，则转到第二个，依此类推。 从 76 到计算出的 goto 的片段是开放编码的子例程。 它是一段类似于子例程的代码，但写在函数体中。 （Fortran 也有语句函数 - 它们是适合单行的嵌入式函数。）

有比计算 goto 更糟糕的结构 - 您可以为变量分配标签，然后使用指定的 goto。 谷歌搜索 分配的 goto 告诉我它已从 Fortran 95 中删除。为结构化编程革命做好准备，这场革命可以说是从 Dijkstra 的“GOTO 被认为有害”的信件或文章开始的。

如果不了解 Fortran 中所做的事情（以及其他语言中的事情，其中​​大多数已经被抛在一边），我们这些新手很难理解 Dijkstra 正在处理的问题的范围。 哎呀，直到那封信发表十年后我才开始编程（但我确实不幸使用 Fortran IV 编程了一段时间）。

Answer 10

后藤认为很有帮助。

我从 1975 年开始编程。对于 20 世纪 70 年代的程序员来说，“goto 被认为是有害的”这句话或多或少表明具有现代控制结构的新编程语言值得尝试。 我们确实尝试了新语言。 我们很快就转变了。 我们再也没有回去过。

我们再也没有回去过，但是，如果你还年轻，那么你一开始就从来没有去过那里。

现在，古代编程语言的背景可能没有多大用处，除非可以作为程序员年龄的指标。 尽管如此，年轻的程序员缺乏这种背景，因此他们不再理解“goto 被认为有害”这一口号在推出时向其目标受众传达的信息。

不理解的口号并不具有启发性。 。 也许最好忘记这些口号。 这样的口号没有帮助。

然而，“后藤被认为是有害的”这个特殊的口号已经拥有了它自己的不死生命。

goto能不被滥用吗？ 答案：当然可以，但是那又怎样呢？ 实际上，每个编程元素都可能被滥用。 例如，不起眼的 bool 被滥用的次数比我们中一些人想象的要多。

相比之下，自 1990 年以来，我不记得遇到过任何实际的 goto 滥用实例。goto

的最大问题可能不是技术问题，而是社会问题。 不太了解的程序员有时似乎觉得弃用 goto 让他们听起来很聪明。 您可能有时必须满足这样的程序员。 这就是人生。

今天goto最糟糕的地方是它没有被充分利用。

Answer 11

原始论文应该被认为是“无条件 GOTO 被认为是有害的”。 它特别提倡一种基于条件 (if) 和迭代 (while) 结构的编程形式，而不是早期代码中常见的测试和跳转。 goto 在某些语言或不存在适当控制结构的情况下仍然有用。

Answer 12

实际上，我发现自己被迫使用 goto，因为我确实想不出更好（更快）的方法来编写这段代码：

我有一个复杂的对象，我需要对其进行一些操作。 如果对象处于一种状态，那么我可以执行快速版本的操作，否则我必须执行慢速版本的操作。 问题是，在某些情况下，在慢速操作的中间，有可能意识到这可以通过快速操作来完成。

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

这是实时 UI 代码中速度关键的一段，所以我真的认为 GOTO 在这里是合理的。

雨果

Answer 13

在 Linux 中：在内核代码中使用 goto 在 Kernel Trap 上，与 Linus Torvalds 和一个“新人”讨论了在 Linux 代码中使用 GOTO。 其中有一些非常好的观点，Linus 也表现出了一贯的傲慢态度:)

一些段落：

Linus：“不，你已经被洗脑了
CS人认为尼克劳斯
沃斯实际上知道他是什么
谈论。 他没有。 他不
有一条令人发指的线索。”

-

Linus：“我认为 goto 很好，而且
它们通常比
大量的缩进。”

-

Linus：“当然，用愚蠢的语言
就像帕斯卡一样，标签不能
描述性的，goto 可能很糟糕。”

Answer 14

我从这里的任何答案中都没有看到的一件事是，“转到”解决方案通常比经常提到的结构化编程解决方案之一更有效。

考虑许多嵌套循环的情况，其中使用“goto”而不是一堆 if(breakVariable) 部分显然更有效。 “将循环放入函数并使用 return”的解决方案通常是完全不合理的。 在循环使用局部变量的情况下，您现在必须通过函数参数将它们全部传递，可能会处理由此产生的大量额外麻烦。

现在考虑清理案例，我自己经常使用它，而且很常见，可能是造成许多语言中不可用的 try{} catch {} 结构的原因。 完成同一件事所需的检查和额外变量的数量远比进行跳转的一两条指令要差得多，而且，附加函数解决方案根本不是解决方案。 你不能告诉我这更易于管理或更具可读性。

现在，在许多情况下，代码空间、堆栈使用和执行时间对于许多程序员来说可能并不重要，但是当您处于只有 2KB 代码空间可供使用的嵌入式环境中时，需要 50 字节的额外指令来避免明确定义的指令“goto”只是可笑的，而且这种情况并不像许多高级程序员认为的那么罕见。

“goto 是有害的”这一说法对于转向结构化编程非常有帮助，即使它总是过于概括。 至此，我们都已经听过它了，因此对使用它持谨慎态度（我们应该如此）。 当它显然是适合工作的工具时，我们不需要害怕它。

Answer 15

“在此链接中http://kerneltrap.org/node/553/2131”

具有讽刺意味的是，消除goto 引入了一个错误：省略了自旋锁调用。

Answer 16

我同意 Goto 唯一可以使用的地方是当您需要处理错误时，并且发生错误的每个特定点都需要特殊处理。

例如，如果您正在获取资源并使用信号量或互斥体，则必须按顺序获取它们，并且应该始终以相反的方式释放它们。

有些代码需要一种非常奇怪的模式来获取这些资源，并且您不能只编写一个易于维护和理解的控制结构来正确处理这些资源的获取和释放以避免死锁。

不使用 goto 总是可以正确完成任务，但在这种情况下以及其他一些情况下，Goto 实际上是更好的解决方案，主要是为了可读性和可维护性。

-亚当

Answer 17

拒绝程序员使用 GOTO 语句就像告诉木匠不要使用锤子，因为当他敲钉子时可能会损坏墙壁。 真正的程序员知道如何以及何时使用 GOTO。 我跟踪了一些所谓的“结构化程序”，我看到了这样可怕的代码，只是为了避免使用 GOTO，这样我就可以射击程序员。 好吧，为了保护另一方，我一次又一次地看到了一些真正的意大利面条代码，那些程序员也应该被枪杀。

这只是我找到的代码的一个小示例。

  YORN = ''
  LOOP
  UNTIL YORN = 'Y' OR YORN = 'N' DO
     CRT 'Is this correct? (Y/N) : ':
     INPUT YORN
  REPEAT
  IF YORN = 'N' THEN
     CRT 'Aborted!'
     STOP
  END

- - - - - - - - - - - -或者 - - - - - - - - - - -

10:  CRT 'Is this Correct (Y)es/(N)o ':

     INPUT YORN

     IF YORN='N' THEN
        CRT 'Aborted!'
        STOP
     ENDIF
     IF YORN<>'Y' THEN GOTO 10

Answer 18

我们已经进行了讨论，我支持我的观点。

此外，我厌倦了人们将高级语言结构描述为“变相的goto”，因为他们显然根本没有明白要点。 例如：

即使是Scheme中先进的延续控制结构也可以被描述为一个复杂的goto。

这完全是无稽之谈。 每个控制结构都可以用goto来实现，但这种观察是完全微不足道且无用的。 goto 不被认为是有害的，因为它有积极的影响，但因为它有负面的后果，而这些后果已被结构化编程所消除。

同样，说“GOTO 是一个工具，并且与所有工具一样，它可以被使用和滥用”也是完全没有道理的。 现代建筑工人不会使用岩石并声称它“是一种工具”。 岩石已被锤子取代。 goto 已被控制结构取代。 如果建筑工人被困在野外，没有锤子，他当然会用石头代替。 如果程序员必须使用不具备 X 功能的劣质编程语言，那么她当然可能必须使用 goto 来代替。 但是，如果她在其他地方使用它而不是适当的语言功能，那么她显然没有正确理解该语言并且错误地使用了它。 真的就是这么简单。

Answer 19

如果 GOTO 本身是邪恶的，那么编译器也会是邪恶的，因为它们生成 JMP。 如果跳转到代码块（尤其是跟随指针）本质上是邪恶的，那么 RETurn 指令也将是邪恶的。 相反，邪恶在于滥用的可能性。

有时，我不得不编写必须跟踪多个对象的应用程序，其中每个对象必须遵循复杂的状态序列来响应事件，但整个事情绝对是单线程的。 如果用伪代码表示，典型的状态序列将是：

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

我确信这不是新的，但我在 C(++) 中处理它的方式是定义一些宏：

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

然后（假设状态最初为 0）上面的结构化状态机变成了结构化代码：

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

对此进行了变体，可以有 CALL 和 RETURN，因此某些状态机可以像其他状态机的子例程一样运行。

这很不寻常吗？ 是的。 维护者需要学习一些知识吗？ 是的。 这种学习有回报吗？ 我想是这样。 如果没有跳转到块的 GOTO 是否可以完成？ 没有。

Answer 20

在 C 和 C++（以及其他罪魁祸首）标记出中断和继续之前，goto 将继续发挥作用。

Answer 21

在我的程序清单中，Goto 的位置非常靠后。 这并不意味着这是不可接受的。

Goto 对于状态机来说非常有用。 循环中的 switch 语句是（按照典型重要性的顺序）：（a）实际上并不代表控制流，（b）丑陋，（c）根据语言和编译器可能效率低下。 因此，您最终会为每个状态编写一个函数，并执行诸如“return NEXT_STATE;”之类的操作 甚至看起来像 goto。

诚然，以易于理解的方式对状态机进行编码是很困难的。 然而，这些困难都与使用 goto 无关，并且不能通过使用替代控制结构来减少这些困难。 除非你的语言有“状态机”结构。 我的没有。

在极少数情况下，当您的算法确实最容易理解时，通过一系列节点（状态）的路径通过一组有限的允许转换（goto）连接，而不是通过任何更具体的控制流（循环、条件等） ），那么这应该在代码中明确表示。 你应该画一个漂亮的图表。

setjmp/longjmp 非常适合实现异常或类似异常的行为。 虽然没有受到普遍赞扬，但异常通常被认为是“有效”的控制结构。

setjmp/longjmp 比 goto “更危险”，因为它们更难正确使用，更不用说理解性了。

从来没有，将来也不会
永远是，任何语言
一点点难写不好
代码。 ——唐纳德·高德纳。

从 C 中去掉 goto 并不会让用 C 编写好的代码变得更容易。事实上，它宁愿忽略 C 应该能够充当一种美化的汇编语言的这一点。

接下来是“被认为有害的指针”，然后是“被认为有害的鸭子类型”。 那么当他们来夺走你不安全的编程结构时，谁会来保护你呢？ 呃？

Answer 22

我只记得使用过一次 goto。 我有一系列五个嵌套计数循环，我需要能够根据某些条件尽早从内部突破整个结构：

    for{
      for{
        for{
          for{
            for{
              if(stuff){
                GOTO ENDOFLOOPS;
              }
            }
          }
        }
      }
    }
    
    ENDOFLOOPS:

我可以轻松声明一个布尔中断变量并将其用作条件的一部分每个循环，但在这种情况下，我认为 GOTO 同样实用且可读。

没有迅猛龙攻击我。

Answer 23

有时，使用 GOTO 作为单个函数中异常处理的替代方法是有效的：

    if (f() == false) goto err_cleanup;
    if (g() == false) goto err_cleanup;
    if (h() == false) goto err_cleanup;
    
    return;
    
    err_cleanup:
    ...

COM 代码似乎经常陷入这种模式。

Answer 24

如果您正在用 C 语言编写 VM，则事实证明，使用（gcc 的）计算 goto 的速度

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

比循环内的传统 switch 快得多。

Answer 25

以下陈述是概括性的； 虽然总是可以提出例外请求，但通常（以我的经验和拙见）不值得冒险。

1. 不受限制地使用内存地址（GOTO 或原始指针）提供了太多犯容易避免的错误的机会。
2. 到达代码中特定“位置”的方法越多，人们对此时系统状态的信心就越低。 （见下文。）
3. 恕我直言，结构化编程并不是“避免 GOTO”，而是更多地使代码结构与数据结构相匹配。 例如，重复的数据结构（例如数组、顺序文件等）自然由重复的代码单元处理。 拥有内置结构（例如 while、for、until、for-each 等）可以让程序员避免重复相同陈词滥调的代码模式的乏味。
4. 即使 GOTO 是低级实现细节（并非总是如此！），它也低于程序员应该考虑的级别。 有多少程序员用原始二进制来平衡他们的个人支票簿？ 有多少程序员担心磁盘上的哪个扇区包含特定记录，而不是仅仅为数据库引擎提供密钥（如果我们真的根据物理磁盘扇区编写所有程序，有多少种情况可能会出错）？

上述脚注：

关于第 2 点，请考虑以下代码：

    a = b + 1
    /* do something with a */

在代码中的“做某事”点，我们可以高度自信地声明 a 大于 b。 （是的，我忽略了未捕获整数溢出的可能性。我们不要陷入一个简单的例子。）

另一方面，如果代码是这样读的：

    ...
    goto 10
    ...
    a = b + 1
    10: /* do something with a */
    ...
    goto 10
    ...

到达标签 10 的方法有多种，这意味着我们必须更加努力地对 a 和 b 之间的关系充满信心。 （事实上​​，在一般情况下，它是不可判定的！）

关于第 4 点，代码中“去某个地方”的整个概念只是一个隐喻。 除了电子和光子（用于废热）之外，没有任何东西真正“移动”到 CPU 内部的任何地方。 有时我们会放弃另一种更有用的隐喻。 我记得遇到过（几十年前！）一种

    if (some condition) {
      action-1
    } else {
      action-2
    }

在虚拟机上实现的语言，方法是将action-1和action-2编译为外线无参数例程，然后使用单个双参数VM操作码，该操作码使用布尔值调用其中之一的条件的值。 这个概念只是“选择现在调用什么”而不是“去这里或去那里”。 再说一遍，只是比喻的改变。

Answer 26

只要你能够独立思考，就永远不会。

Answer 27

因为 goto 可用于混淆元编程，所以

Goto 既是高级控制表达式，又是低级控制表达式，因此它没有适合大多数问题的适当设计模式。

从某种意义上说，它是低级，因为 goto 是一种原始操作，它实现了 while 或 foreach 等更高级别的操作。

它是高级，因为当以某些方式使用时，它采用以清晰的顺序、不间断的方式执行的代码（结构化循环除外），并将其更改为逻辑片段，有足够的goto，动态重组的逻辑的抓包。

因此，goto 有平淡和邪恶的一面。

平淡无奇的一面是，向上的 goto 可以实现完全合理的循环，而向下的 goto 可以实现完全合理的 break 或 return 。 当然，实际的 while、break 或 return 会更具可读性，因为可怜的人不必模拟goto 的效果以获得全局。 所以，总的来说，这是一个坏主意。

邪恶的一面涉及一个例程，不使用 goto 来执行 while、break 或 return，而是将其用于所谓的意大利面条逻辑。 在这种情况下，喜欢 goto 的开发人员正在从 goto 的迷宫中构建代码片段，理解它的唯一方法是在心理上模拟它作为一个整体，当有很多 goto 时，这是一项非常累人的任务。 我的意思是，想象一下评估代码时的麻烦，其中 else 并不完全是 if 的逆，其中嵌套的 if 可能允许在某些情况下使用 语句

最后，为了真正涵盖这个主题，我们应该注意到，基本上除了 Algol 之外的所有早期语言最初只做出了受其 if-then-else。 因此，执行条件块的唯一方法是使用逆条件goto来绕过它。 我知道这很疯狂，但我读过一些旧规格。 请记住，第一台计算机是用二进制机器代码编程的，因此我认为任何类型的 HLL 都是救星； 我想他们对于自己获得的 HLL 功能并不太挑剔。

说了这么多，我曾经在我编写的每个程序中都插入了一个 goto，“只是为了惹恼纯粹主义者”。

Answer 28

自从我开始在 Linux 内核中做一些事情以来，goto 不再像以前那样困扰我了。 起初，我有点震惊地看到他们（内核人员）在我的代码中添加了 goto。 从那时起，我已经习惯了在某些有限的上下文中使用 goto，现在我自己也会偶尔使用它们。 通常，它是跳转到函数末尾以执行某种清理和救助的 goto，而不是在函数中的多个位置重复相同的清理和救助。 通常情况下，它的大小不足以传递给另一个函数——例如，释放一些本地 (k)malloc 的变量是一个典型的情况。

我编写的代码只使用了一次 setjmp/longjmp 。 它位于 MIDI 鼓音序器程序中。 播放发生在与所有用户交互无关的单独进程中，并且播放进程使用与 UI 进程共享的内存来获取播放所需的有限信息。 当用户想要停止播放时，播放过程只是执行一个 longjmp“回到开头”来重新开始，而不是在用户希望停止时对它恰好正在执行的位置进行一些复杂的展开。 它工作得很好，很简单，在那种情况下我从未遇到过任何与之相关的问题或错误。

setjmp/longjmp 有它们的位置——但那个地方你不太可能访问，但很长一段时间才会访问一次。

编辑：我刚刚看了代码。 实际上我使用的是 siglongjmp()，而不是 longjmp（并不是说这有什么大不了的，但我忘记了 siglongjmp 甚至存在。）

Answer 29

不存在GOTO 被认为有害的事情。

GOTO 是一个工具，并且与所有工具一样，它可以被使用和滥用。

然而，编程世界中的许多工具往往被滥用多于使用，GOTO 就是其中之一。 Delphi 的 WITH 语句是另一个。

就我个人而言，我在典型代码中不使用任何一个，但我有过 GOTO 和WITH 的奇怪用法，这是有保证的，并且另一种解决方案将包含更多代码。

最好的解决方案是编译器只是警告您关键字被污染，并且您必须在语句周围填充一些杂注指令以消除警告。

这就像告诉您的孩子不要拿着剪刀奔跑。 剪刀不错，但使用它们可能并不是保持健康的最佳方法。

Answer 30

今天，很难看出 GOTO 语句有什么大不了的，因为“结构化编程”人们大多赢得了这场辩论，而且今天的语言有足够的控制流结构来避免 GOTO。

计算现代 C 程序中 goto 的数量。 现在添加 break、continue 和 return 语句的数量。 此外，添加使用 if、else、while、switch 或 case< 的次数/代码>。 这大约是如果您在 1968 年 Dijkstra 写信时使用 FORTRAN 或 BASIC 编写程序，那么您的程序将有多少个 GOTO。

当时的编程语言缺乏控制流。 例如，在最初的 Dartmouth BASIC 中：

• IF 语句没有 ELSE。 如果你想要一个，你必须写：

  100 IF NOT 条件 THEN GOTO 200 
    ...如果条件为真则要做的事情... 
    190 转到 300 
    200 REM 其他 
    ...如果条件为假则要做的事情... 
    300 REM 结束如果 
    

• 即使您的 IF 语句不需要 ELSE，它仍然限于一行，这通常由 GOTO 组成。

• 没有 DO...LOOP 语句。 对于非 FOR 循环，您必须使用显式 GOTO 或 IF...GOTO 结束循环，回到开头。

• 没有SELECT CASE。 您必须使用ON...GOTO。

因此，您的程序中最终出现了很多的GOTO。 并且您不能依赖于单个子例程中的 GOTO 限制（因为 GOSUB...RETURN 是子例程的一个弱概念），因此这些 < code>GOTO 可以去任何地方。 显然，这使得控制流程难以遵循。

这就是反GOTO运动的由来。