使用什么而不是Goto语句?

时间:2014-04-16 19:08:19

标签: c++ if-statement goto

我想知道我应该使用什么代替goto语句?

我应该使用嵌套的if / while / do-while语句吗?

他们说使用goto会创建'意大利面条代码',但是如果有人正在编写一个大型控制台应用程序并且他们在if语句之后使用if语句来试图控制流程,那么这会变得一团糟吗?

我问很多人都问过为什么goto声明不好,而不是用什么来代替它。我相信很多初学者都可以做到这一点。

这适用于C ++。

5 个答案:

答案 0 :(得分:7)

使用函数,循环和条件语句会好得多。使用break并根据需要继续。

我几乎可以保证你使用goto的任何情况都有更好的选择。有一个值得注意的例外:多级休息。

while(1){
    while(1){
        goto breakOut;
    }
    //more code here?
}
breakOut:

在这个(相对)罕见的情况下,可以使用goto代替典型的“中断”,以明确我们实际上已经脱离了嵌套循环。另一种方法是使用“完成”变量:

while(!done){
    while(!done){
        done = true;
        break;
    }
    if(done){break;}
    //More code here?  If so, the above line is important!
}

正如您所看到的,当您在外部循环中进行额外处理时,done变量更加冗长,因此goto是一种更清晰的自由方式!

然而,在99%的情况下,你真的,真的,不想开始写一堆goto语句。真的想过每一个。

使用上述功能也可以这样写:

bool innerLoop(){
    while(1){
        return false;
    }
    return true;
}

...
while(innerLoop()){ //can only be written this way if the inner loop is the first thing that should run.
    //More code here?
}
...

如果在外部循环中存在大量依赖关系,有时以这种方式打破内部循环可能会很混乱。但它仍然是一种可靠的方法,可以使用return语句而不是goto或break来提前破解代码。

答案 1 :(得分:3)

如果您可以使用干净的现代构造编写逻辑,那么请使用它。否则,如果goto有意义,请使用它。

通常,goto会使您的代码更难以阅读并遵循代码流程。出于这个原因,新手被告知要完全避免goto。这鼓励他们从其他结构的角度思考。

但有些人只是对此有所了解。编码不是宗教。如果goto有意义,C ++有一个完全有效的goto语句,你应该在它有道理的时候使用它。

要问你应该使用什么而不是goto,这对我来说没有意义。您通常可以使用某种类型的循环或其他构造,具体取决于您正在做什么。但是goto有意义,请使用它。

答案 2 :(得分:2)

不要听那些说“从不使用goto”的人。你是完全正确的,有些情况下,嵌套范围的块会比goto更加混乱。它有它的位置,就像switch / case一样。 然而,通过功能,您通常可以重构整个论点并让人们满意。

答案 3 :(得分:0)

简单地忘记在C ++中有goto语句,并且不会有关于如何替换goto的问题。:)

至于我,我从来没有看到过goto语句的代码,我可以称之为一个好的代码。通常goto语句是某种错误和困难的根源。特别是很难修改这样的代码。此外,一个goto语句通常会在代码中开始生成其他goto语句。:)

答案 4 :(得分:0)

goto很糟糕,因为它允许您从上下文跳转到上下文。上下文是程序中特定点的所有变量(及其值)的向量。程序执行图显示程序如何从上下文跳转到上下文。保持执行图尽可能简单符合您的最佳利益。最简单的是链,下一步是执行树。循环增加了复杂性,但它是托管复杂性。如果执行图中有一个节点,可以通过多个执行路径访问,并且您需要了解该节点的上下文,那么您需要遵循多个执行路径。这些“合并”节点大大增加了程序的复杂性。每个带标签的语句(goto目标)都是潜在的合并节点。

所以,尝试根本不使用goto运算符 - 语言本身将强制您使用循环,布尔变量,类,函数等找到可管理的解决方案。你的程序将更加清晰易懂。 C ++异常是另一种在上下文之间跳转的可管理方式。

有计算天才,他们可以记住并处理非常复杂的执行图,因此他们不关心程序的复杂性或下一个程序员,他们将被分配来支持或接管他们的代码未来。我想,我们在这里有一些:-)