GOTO仍然被认为有害?

每个人都知道Dijkstra的《致编辑的信》:goto语句被认为是有害的(这里。html transcript和这里。pdf)，从那时起，就有一种强大的推动力，尽可能避免使用goto语句。虽然可以使用goto来生成不可维护的、庞大的代码，但它仍然存在于现代编程语言中。即使Scheme中先进的连续控制结构也可以被描述为复杂的后向。

在什么情况下需要使用goto?什么时候最好避免?

作为一个后续问题:C提供了一对函数setjmp()和longjmp()，它们不仅提供了在当前堆栈帧内进行跳转的能力，还提供了在任何调用帧内进行跳转的能力。这些应该被认为和goto一样危险吗?更危险?

Dijkstra自己也对这个头衔感到后悔，因为这不是他的责任。在EWD1308的结尾(也在这里。pdf)，他写道:

Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.

Donald E. Knuth写了一篇关于这个主题的经典论文，它与Dijkstra的论文相匹配，那就是结构化编程与语句。阅读既有助于重建上下文，也有助于对主题的非教条性理解。在本文中，Dijkstra对这个案例的观点被报道，并且更加强烈:

Donald E. Knuth:我相信通过呈现这样一个事实上，我并不是不同意 Dijkstra的观点，因为他最近写道: “请不要落入。相信我是可怕的教条的关于[去]的教条的声明)。我觉得很不舒服感觉别人在做宗教出来了，好像编程的概念问题只用一个小技巧就能解决，用什么一种简单的编码纪律!”

当前回答

跳跃的例子在Java字符串类源代码:

int firstUpper;

/* Now check if there are any characters that need to be changed. */
scan: {
    for (firstUpper = 0 ; firstUpper < count; ) {
         char c = value[offset+firstUpper];
         if ((c >= Character.MIN_HIGH_SURROGATE) &&
                 (c <= Character.MAX_HIGH_SURROGATE)) {
             int supplChar = codePointAt(firstUpper);
             if (supplChar != Character.toLowerCase(supplChar)) {
                  break scan;
             }
             firstUpper += Character.charCount(supplChar);
         } else {
             if (c != Character.toLowerCase(c)) {
                  break scan;
             }
             firstUpper++;
         }
     }
     return this;
}
[... subsequent use of firstUpper ...]

这可以用很少的开销重写，例如:

 int firstUpper = indexOfFirstUpper();
 if (firstUpper < 0) return this;

即使在现代语言中，即使我实际上不喜欢使用gotos，但我认为它们在许多情况下是可以接受的，在像这样的低级情况下，我看起来更好(它不仅仅是退出循环)。

没有激起宗教战争的意图。

2013-02-19 15:13:46

其他回答

直到C和c++(以及其他罪魁祸首)标记了断点和继续，goto将继续发挥作用。

2008-09-06 14:44:38

实际上，我发现自己不得不使用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在这里是合理的。

Hugo

2009-01-17 18:55:14

几乎所有可以使用goto的情况，都可以使用其他结构实现相同的效果。无论如何，编译器都会使用Goto。

我个人从来没有明确地使用它，也不需要。

2010-06-17 07:41:44

我唯一同意使用Goto的地方是当你需要处理错误时，每一个特定的错误点都需要特殊的处理。

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

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

在没有goto的情况下总是可以做得很好，但在这种情况下和其他一些情况下，goto实际上是更好的解决方案，主要是为了可读性和可维护性。

亚当

2008-09-05 19:45:19