C# 語言
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; } }
C語言
統計從鍵盤輸入一行字元的個數。
#include<stdio.h>int n=0;int main(void) { printf("input a string: "); loop: if (getchar()!='\n') { n++; goto loop; } printf("output: %d\n",n);}
例如輸入:abcdefghijklmnopqrstuvwxyz
然後回車Enter
輸出:26
本例用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:是標號
Pascal
格式 goto <標號>;
其中標號需要申請,在程式開頭寫label <標號1>,<標號2>,……;
其中,標號必須為四位以內的正整數。
在該段落內還需要有<標號>:語句 表示將要轉向的方向。
delphi
//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 開始
VBA
使用冒號做標記,但是跟批處理的不一樣,冒號在後面
start:
goto start
發展歷程
問題起源:
60年代中期以後,計算機硬體技術日益進步,計算的存貯容量、運算速度和可靠性明顯提高,生產硬體的成本不斷降低。計算機價格的下跌為它的廣泛套用創造了極好的條件。在這種形勢下,迫切要求計算機軟體也能與之相適應。因而,一些開發大型軟體系統的要求提了出來。然而軟體技術的進步一直未能滿足形勢發展的需要,在大型軟體的開發過程中出現了複雜程度高、研製周期長、正確性難以保證的三大難題。遇到的問題找不到解決辦法,致使問題堆積起來,形成了人們難以控制的局面,出現了所謂的“
軟體危機”。為了克服這一危機,一方面需要對程式設計方法、程式的正確性和軟體的可靠性等問題進行系列的研究;另一方面,也需要對軟體的編制、測試、維護和管理的方法進行研究,從而產生了
程式設計方法學。
goto語句是有害的觀點:
1968年,Edsger Wybe Dijkstra 首先提出“GOTO語句是有害的”論點,向傳統程式設計方法提出了挑戰,從而引起了人們對程式設計方法討論的普遍重視。
goto語句的爭論:
在60年代末和70年代初,關於GOTO語句的用法的爭論比較激烈。主張從高級程式語言中去掉GOTO語句的人認為,GOTO語句是對程式結構影響最大的一種有害的語句,他們的主要理由是:GOTO語句使程式的靜態結構和動態結構不一致,從而使程式難以理解,難以查錯。去掉GOTO語句後,可直接從程式結構上反映程式運行的過程。這樣,不僅使程式結構清晰,便於理解,便於查錯,而且也有利於程式的正確性證明。
持反對意見的人認為,GOTO語句使用起來比較靈活,而且有些情形能提高程式的效率。若完全刪去GOTO語句,有些情形反而會使程式過於複雜,增加一些不必要的計算量。
關於goto語句的解決方法:
1974年,D·E·克努斯對於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語句問題的提出直接推動了結構化程式設計(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)應該避免向兩個方向跳轉。這樣最容易導致"麵條代碼"。