网站地图
goto语句

goto语句也称为无条件转移语句,其一般格式如下: goto 语句标号; 其中语句标号是按标识符规定书写的符号, 放在某一语句行的前面,标号后加冒号(:)。语句标号起标识语句的作用,与goto 语句配合使用。

如: label: i++;

loop: while(x<7);

C语言不限制程序中使用标号的次数,但各标号不得重名。goto语句的语义是改变程序流向, 转去执行语句标号所标识的语句。

goto语句通常与条件语句配合使用。可用来实现条件转移, 构成循环,跳出循环体等功能。

但是,在结构化程序设计中一般不主张使用goto语句, 以免造成程序流程的混乱,使理解和调试程序都产生困难。

using System;

using static System.Console;

class Program

{

public static Int32 Main(String[]args)
  {
  int n = 0;
  WriteLine("input a string :\n");
  loop: if (Read()!= '\r')
  {
  n++;
  goto loop;
  }
  WriteLine("{0}", n);
  return 0;
  }
  }

统计从键盘输入一行字符的个数。

#include<stdio.h>

int main(void){

int n=0;

printf("input a string :\n");

loop: if(getchar()!='\n'){

n++;

goto loop;

}

printf("%d",n);

}

例如输入:abcdefghijklmnoprstu

然后回车Enter

输出:20

本例用if语句和goto语句构成循环结构。当输入字符不为'\n'时即执行n++进行计数,然后转移至if语句循环执行。直至输入字符为'\n'才停止循环。

goto语句与汇编语言里面的jmp指令相同,(无条件转移)

1+2+3........+8+9+10

NASM描述:

mov ax,1

mov bx,0

start:add bx,ax

inc ax

cmp ax,11;比较指令

jzend ;零转移

jmp start

end:

;

;start: end:是标号

格式 goto <标号>;

其中标号需要申请,在程序开头写label <标号1>,<标号2>,……;

其中,标号必须为四位以内的正整数。

在该段落内还需要有<标号>:语句 表示将要转向的方向。

//Goto语句用在跳转行号, 可以跳转到当前结构层内任意位置.

//必须在声明处用label关键字声明行号.

//由于Goto语句会破坏程序的结构, 不推荐使用.

var

a,b: Integer;

label

X,Y;

begin

if a > b then

goto X

else

goto Y;

X:

WriteLn('a > b');

Y:

WriteLn('b > a');

end;

使用冒号标记

:start

goto start

使用rem做标记,可以用中文

rem 开始

goto 开始

使用冒号做标记,但是跟批处理的不一样,冒号在后面

start:

goto start

问题起源:

60年代中期以后,计算机硬件技术日益进步,计算的存贮容量、运算速度和可靠性明显提高,生产硬件的成本不断降低。计算机价格的下跌为它的广泛应用创造了极好的条件。在这种形势下,迫切要求计算机软件也能与之相适应。因而,一些开发大型软件系统的要求提了出来。然而软件技术的进步一直未能满足形势发展的需要,在大型软件的开发过程中出现了复杂程度高、研制周期长、正确性难以保证的三大难题。遇到的问题找不到解决办法,致使问题堆积起来,形成了人们难以控制的局面,出现了所谓的“软件危机”。为了克服这一危机,一方面需要对程序设计方法、程序的正确性和软件的可靠性等问题进行系列的研究;另一方面,也需要对软件的编制、测试、维护和管理的方法进行研究,从而产生了程序设计方法学。

goto语句是有害的观点:

1968年,Edsger Wybe Dijkstra 首先提出“GOTO语句是有害的”论点,向传统程序设计方法提出了挑战,从而引起了人们对程序设计方法讨论的普遍重视。

goto语句的争论:

在60年代末和70年代初,关于GOTO语句的用法的争论比较激烈。主张从高级程序语言中去掉GOTO语句的人认为,GOTO语句是对程序结构影响最大的一种有害的语句,他们的主要理由是:GOTO语句使程序的静态结构和动态结构不一致,从而使程序难以理解,难以查错。去掉GOTO语句后,可直接从程序结构上反映程序运行的过程。这样,不仅使程序结构清晰,便于理解,便于查错,而且也有利于程序的正确性证明。

持反对意见的人认为,GOTO语句使用起来比较灵活,而且有些情形能提高程序的效率。若完全删去GOTO语句,有些情形反而会使程序过于复杂,增加一些不必要的计算量。

关于goto语句的解决方法:

1974年,DE克努斯对于GOTO语句争论作了全面公正的评述,其基本观点是:不加限制地使用GOTO语句,特别是使用往回跳的GOTO语句,会使程序结构难于理解,在这种情形,应尽量避免使用GOTO语句。但在另外一些情况下,为了提高程序的效率,同时又不至于破坏程序的良好结构,有控制地使用一些GOTO语句也是必要的。用他的话来说就是:“在有些情形,我主张删掉GOTO语句;在另外一些情形,则主张引进GOTO语句。”从此,使这场长达10年之久的争论得以平息。

后来,G加科皮尼和C波姆从理论上证明了:任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明,从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力,而且编写的程序的结构更加清晰。

goto语句的结果:

在C/C++等高级编程语言中保留了goto语句,但被建议不用或少用。在一些更新的高级编程语言,如Java不提供goto语句,它虽然指定goto作为关键字,但不支持它的使 用,使程序简洁易读;尽管如此后来的c#还是支持goto语句的,goto语句一个好处就是可以保证程序存在唯一的出口,避免了过于庞大的if嵌套。

二.可以考虑使用goto的情形

1.从多重循环中直接跳出

很多人建议废除C++/C的goto语句,以绝后患。但实事求是地说,错误是程序员自己造成的,不是goto的过错。goto 语句至少有一处可显神通,它能从多重循环体中一下子跳到外面,用不着写很多次的break语句。例如:

for(......){

for(....){

for(.....){

// 如何冲出重重包围?

}

}

}

break;只能跳出单层的循环,return将整个函数都返回了,没法再继续了,显然也不行,所以我们想到了goto。如果是在陷入了很深层次的循环里想要跳出最外层的循环,用 goto 直接跳出却比用 break 一个循环一个循环地跳出要好得多。有人甚至形象比喻说:“就像楼房着火了,来不及从楼梯一级一级往下走,可从窗口跳出火坑。” 其实,你可以将 break 和 continue 理解成弱化了的 goto 语句。

2. 出错时清除资源

如果一个函数有多个出口,则在每个出口处,会产生巨大的退出代码,如下例一,每个函数只能有一个出口,所有的资源释放必须放在出口统一解决,那全部使用大括号,十几个,几十个if判断条件下来,你数数你的大括号有多深?这种代码可读性不好,一旦写错了,难于寻找错误。所有这些问题,一个goto就解决了。

当程序要分配和清除资源时(像内存、或处理字形、窗口、打印机),这种情形下用goto通常是为了复制代码或清除资源。若遇到这种情况,程序员就要掂量是 goto 的缺点令人讨厌呢?还是复制代码那令人头痛的维护更讨厌呢?最后还是认为 goto 的缺点更可忍受。

例子一:不用goto,想想需要申请的指针是10个的话,程序怎么写?

void Func(void)

{

char* p1=null;

char* p2=null;

char* p3=null;

p1=(char*)malloc(10);

if(!p1) return;

p2=(char*)malloc(10);

if(!p2)

{

free(p1);

p1=null;

return;

}

p3=(char*)malloc(10);

if(!p3)

{

free(p1);

p1=null;

free(p2);

p2=null;

return;

}

……

……

…… //指针使用过程

if(p1)

{

free(p1);

p1=null;

}

if(p2)

{

free(p2);

p2=null;

}

if(p3)

{

free(p3);

p3=null;

}

}

例子二:用goto

void Func(void)

{

char* p1=null;

char* p2=null;

char* p3=null;

p1=(char*)malloc(10);

if(!p1) goto Func_End_Process;

p2=(char*)malloc(10);

if(!p2) goto Func_End_Process;

p3=(char*)malloc(10);

if(!p3) goto Func_End_Process;

……

……

…… //指针使用过程

Func_End_Process:

if(p1)

{

free(p1);

p1=null;

}

if(p2)

{

free(p2);

p2=null;

}

if(p3)

{

free(p3);

p3=null;

}

}

3.可增加程序的清晰度的情况。

若不使用goto语句会使功能模糊,有时候使用goto语句,一眼就看清楚了程序的意图,可用那些对应的循环break语句等实现的语句段,要想老半天才搞清楚程序意图的情况,也可考虑使用goto语句。

三.不加限制地使用goto带来的弊端

1).很明显,不加限制地使用goto破坏了清晰的程序结构,使程序的可读性变差,甚至成为不可维护的"面条代码"。例如下例:

[code=C/C++]

A: //code section A

//code

goto B;

//code

goto C;

B: //code section B

//code

goto A;

//code

goto C;

C: //code section C

//code

//goto B;

//code

goto A;

[/code]

这样好像已经能够说明问题了,随着标签的增多,带来的混乱局面是很难扭转的,对调试,走读,理解代码都会造成很大的障碍,如果你写这样的代码,那代码维护绝对会是一场 噩梦。

2). 不加限制地使用goto经常带来错误或隐患。它可能跳过了某些对象的构造、变量的初始化、重要的计算等语句,例如:

goto state;

String s1, s2; // 被goto 跳过

int sum = 0; // 被goto 跳过

…..

……

state:

……

如果编译器不能发觉此类错误,每用一次goto 语句都可能留下隐患。

四.Goto语句与结构化程序设计

goto语句问题的提出直接推动了结构化程序设计(structured programming)的思想和程序设计方法学的诞生和发展。结构化程序设计方法引入了工程思想和结构化思想,使大型软件的开发和编程都得到了极大的改善。

结构化程序设计方法的主要原则可以概括为自顶向下,逐步求精,模块化,限制使用goto语句。

1.自顶向下:程序设计时,应先考虑总体,后考虑细节;先考虑全局目标,后考虑局部目标。不要一开始就过多追求众多的细节,先从最上层总目标开始设计,逐步使问题具体化。

2.逐步求精:对复杂问题,应设计一些子目标作为过渡,逐步细化。

3.模块化:一个复杂问题,肯定是由若干稍简单的问题构成。模块化是把程序要解决的总目标分解为子目标,再进一步分解为具体的小目标,把每一个小目标称为一个模块。

4.限制使用goto语句

结构化程序设计方法的起源来自对goto语句的认识和争论。肯定的结论是,在块和进程的非正常出口处往往需要用goto语句,使用goto语句会使程序执行效率较高;在合成程序目标时,goto语句往往是有用的,如返回语句用goto。否定的结论是,goto语句是有害的,是造成程序混乱的祸根,程序的质量与goto语句的数量呈反比,应该在所有高级程序设计语言中取消goto语句。取消goto语句后,程序易于理解、易于排错、容易维护,容易进行正确性证明。作为争论的结论,1974年Knuth发表了令人信服的总结,并证实了:

(1)goto语句确实有害,应当尽量避免;

(2)完全避免使用goto语句也并非是个明智的方法,有些地方使用goto语句,会使程序流程更清楚、效率更高。

(3)争论的焦点不应该放在是否取消goto语句上,而应该放在用什么样的程序结构上。其中最关键的是,应在以提高程序清晰性为目标的结构化方法中限制使用goto语句

五.关于goto使用语句的一些建议

goto语句在结构化编程技术出来后,被当作破坏结构化程序的典型代表,可以说,在结构化程序设计年代,goto语句就像洪水猛兽一样,程序员都唯恐避之不及;可后来在微软的一些例子程序中经常把goto语句用来处理出错,当出错时,goto到函数要退出的一个label那里进行资源释放等操作。那么,goto语句是不是只可以用于出错处理,其他地方都不可以用了呢?下列关于使用goto语句的原则可以供读者参考。

1) 使用goto语句只能goto到同一函数内,而不能从一个函数里goto到另外一个函数里。

2) 使用goto语句在同一函数内进行goto时,goto的起点应是函数内一段小功能的结束处,goto的目的label处应是函数内另外一段小功能的开始处。

3) 不能从一段复杂的执行状态中的位置goto到另外一个位置,比如,从多重嵌套的循环判断中跳出去就是不允许的。

4)应该避免向两个方向跳转。这样最容易导致"面条代码"。


相关文章推荐:
标识符 | 冒号 | 循环结构 | 无条件转移 | 软件危机 | 程序设计方法学 | 指针 | 指针 | 编译器 | 结构化程序设计 | 程序设计方法学 | 结构化程序设计方法 | 逐步求精 | 结构化程序设计方法 | 程序设计语言 | 结构化方法 | 结构化程序 | 结构化程序设计 |
相关词汇词典