1982 年のZX Spectrumホーム コンピュータの「GOTO」キーは、ネイティブBASIC (ワンキー コマンド入力)で実装されています。

コンピュータプログラミングにおいて、gotoは制御フロー 文であり、制御をソースコードの別の行に渡します。関数呼び出しは呼び出し元への戻りをサポートしますが、goto は戻りをサポートしません。goto 文の表記はプログラミング言語によって異なります。小文字 ( goto)、大文字 ( GOTO)、大文字小文字を区別しないなど、また、1つの単語または2つの単語 ( などGO TO) で表す場合もあります。

goto文は、主に機械語 のジャンプ命令（分岐または転送）へのアクセスを提供するために言語に組み込まれていますが、ジャンプセマンティクスの使用に伴う潜在的な問題のため、言語は時間の経過とともに、goto文の必要性と使用を置き換えることを目的とした他のフロー制御メカニズムを拡張してきました。多くの現代の言語にはgoto文が全く含まれていません。goto文を含む多くの言語は、使用によって発生する可能性のある問題を制限するために、goto文の使用を制限しています。さらに、goto文の使用は一般的に不適切な選択肢と見なされているため、ソフトウェア開発者は、goto文を提供する言語を使用している場合でも、goto文の使用を避ける傾向があります。

一般的に、goto の使用は、より構造化されたフロー制御を使用するコードよりも、認知負荷が高くバグが多いコードにつながるため、あまり良い選択ではないと考えられています。goto の使用はコンピュータの黎明期には一般的でしたが、1960年代から1970年代にかけて、goto をより構造化されたフロー制御に置き換えることを目指した構造化プログラミング運動の協調的な取り組みにより、その使用は大幅に減少しました。とはいえ、goto は現在でも使用されていますが、一般的に特定のシナリオに限定されています。

構造化プログラム定理は、フローチャートとして表現できるプログラムを書くのにgoto文は必要ないことを実証した。コードの重複や追加の変数が必要になる可能性があるという注意点があるものの、シーケンス、選択、反復という3つのプログラミング構造の組み合わせで、チューリングマシンで実行できるあらゆる計算を実行できる。[1]

言語サポート

gotoのサポートは言語によって異なります。古く設計された言語は無制限のサポートを提供する傾向があり、新しい言語は制限付き、あるいは全くサポートしない傾向があります。例えば、C言語では別の関数のラベルへのジャンプは許可されていません。[2] [3]

C#とVisual Basic .NETはどちらもgotoをサポートしています。[4] [5]しかし、これらの言語では、包含スコープ外のラベルへのジャンプは許可されておらず、オブジェクトの破棄とfinally構文が尊重されるため、他の言語のgotoに比べて大幅に強力で危険性も低いものとなっています。また、これらの言語では、スコープが囲むswitch文caseとなるラベルとdefaultキーワードが作成されます。また、暗黙的なフォールスルーの代わりに、 またはが使用されますが、これは許可されていません。goto casegoto default

多くの言語にはgoto文のセマンティクスが欠けています。Javaには予約語が ありますが、コンパイルされたファイルはgoto文とラベル文を生成しますgotoが、実際には使用できません。 [説明が必要] [6] Pythonはgoto文をサポートしていませんが、それを提供するジョークモジュールがいくつかあります。[7] [8] PHPはバージョン5.3までgoto文をサポートしていませんでした。[9].class

PL/Iには、ブロック外転送のスタックをアンワインドし、ブロック内への転送を許可しない goto ステートメントがあります。

gotoセマンティクス文を持つ言語のほとんどはキーワードgotoを使用しますが、特に古い言語では他の構文も使用されます。例えば、MADでは[ 10]、APLでは右向きの矢印 を使用します。 TRANSFER TO→

Scheme などの関数型プログラミング言語では、通常、goto は使用されず、代わりに継続が使用されます。

計算して割り当てる

Fortranでは、計算型gotoは式の値に基づいてリスト内の複数のラベルのいずれかにジャンプします。例としては、がありますgoto (20,30,40) i。[11] C言語では同等の構文はswitch文であり、新しいFortranではSELECT CASE構文が推奨される構文の代替手段です。[12] BASICに'On GoTo'は同じ目的を達成する文がありましたが、 Visual Basicではこの構文はサポートされなくなりました。[13]

Fortran 95より前のバージョンでは、Fortranには代入gotoの亜種もあり、これは制御を文ラベル（行番号）に移し、その文ラベルは整数変数に格納（代入）されます。残念ながら、代入されていない整数変数にジャンプすることが可能であり、代入goto文に関連するバグの主な原因でした。[14] Fortranの文では、整数変数に代入できるのは定数（既存）の行番号のみです。しかし、一部のコンパイラでは、その後この変数を誤って整数として扱い、例えばインクリメントしてしまうことがあり、goto時に未指定の動作を引き起こします。次のコードは、 i行目が指定されていない場合assignの動作を示しています。 goto i

    200をiに代入i = i + 1 goto i ! 未指定の動作200 write ( * , * ) "これは有効な行番号です"

いくつかの C コンパイラは、もともとgccによって導入された goto 文に関する 2 つの非標準 C/C++ 拡張を実装しています。[15]void* GNU 拡張では、単項のプレフィックスラベル値演算子 を使って、現在の関数内のラベルのアドレスを として取得できます&&。goto 命令も拡張され、任意の式にジャンプできるようになりました。この C 拡張は、それをサポートする C コンパイラのドキュメントでは計算型 gotovoid*と呼ばれています。計算型 goto の意味は Fortran の割り当て型 goto のスーパーセットです。これは、任意のポインタ式を goto 先として使用できるのに対し、Fortran の割り当て型 goto では任意の式をジャンプ先として使用できないためです。[16] C の標準 goto と同様に、GNU C 拡張では計算型 goto のターゲットを現在の関数内にのみ配置できます。現在の関数外へのジャンプを試みると、未指定の動作が発生します。[16]

BASICのいくつかの派生版では、GNU Cで用いられる意味での計算型gotoもサポートされています。つまり、ターゲットはリスト内の行番号だけでなく、任意の行番号にすることができます。例えば、MTS BASICでは、変数iGOTO i*1000の値（例えば選択されたメニューオプションを表す）の1000倍の行番号にジャンプする命令を書くことができます。[17]

PL/I ラベル変数は、計算または割り当てられた goto の効果を実現します。

変更

1985年まで、ANSI規格COBOLALTERには、 の宛先を変更するための文がありましたがGO TO、これは段落内に単独で記述する必要がありました。このALTER文は1985年COBOL規格では廃止とみなされ、2002年に削除されました（COBOL自己書き換えコードを参照）。ポリモーフィズムを可能にするこの機能は、しばしば非難され、ほとんど使用されませんでした。[18]

Perl の goto

Perlにはgoto文があり、関数名を受け取り、ある関数呼び出しを別の関数呼び出しに置き換えることで制御を移します（末尾呼び出し）。新しい関数はgoto文に戻るのではなく、元の関数が呼び出された場所に戻ります。[19] [説明が必要]

エミュレートされた goto

gotoを直接サポートしていない言語もいくつかありますが、gotoエミュレーションは制限付きではあるものの、gotoに似た機能を提供します。Java、[20]、JavaScript、[21]、Python [7] [8]ではgotoをエミュレートできます。

PL/Iラベル変数

PL /Iのデータ型は、label代入型gotoと計算型gotoの両方を実装するために使用でき、PL/Iでは現在のブロック外への分岐が許可されています。手続きはラベルを引数として受け取り、分岐で終了することができます。ラベル変数の値にはスタックフレームのアドレスが含まれており、ブロック外へのgotoはスタックをポップします。

以下は割り当てられた goto を実装します。 

  whereラベルを宣言します; where = somewhere ; goto where ; ... somewhere: ...

以下は計算された goto を実装します。 

   where ( 5 )ラベルを宣言します。inxを固定として宣言します。where ( 1 ) = abcです。where ( 2 ) = xyzです。... where ( inx )へ移動します。... abc: ... xyz: ...

同等の結果を得る別の方法は、変数を使用しないラベル定数配列labelを使用することです。 

   inx を固定として宣言します。... inxにgotoします。... where ( 1 ) : ... where ( 2 ) : ...

例

構文は言語によって異なりますが、多くの場合、同様のパターンに従います。制御対象はラベルまたは行番号で識別されます。

DOSバッチファイルでは、gotoは実行をラベル（コロンで始まる識別子）に指示します。gotoのターゲットは変数にすることができます。以下は、gotoを使用して計算型gotoによるマルチパス分岐を実装しています。 

@エコーオフSET
 D8str  = %date% SET D8dow = % D8str :~0,3%
 

FOR  %% D in  ( Mon Wed Fri )  do  if  " %% D"  ==  " %D8dow% "  goto  SHOP%%D 
echo今日、%D8dow%はショッピングの日ではありません。
 goto  end

: SHOPMon 
echoランチにピザを買う - 月曜日はピザの日。
終了へ 

: SHOPWed 
echoカルツォーネを買って持ち帰ります - 今日は水曜日です。
終了へ 

: SHOPFri 
echo誰かがゼロカロリーの飲み物を欲しがっている場合に備えて、セルツァーを買ってください。
 :終わり

批判

1959年に開催されたALGOL以前の会議で、ハインツ・ゼマネクはgoto文の必要性を明確に疑問視したが、当時は誰も[引用が必要]、後にgotoの象徴的な反対者となるエドガー・W・ダイクストラを含めて彼の発言に注意を払わなかった。 [22] 1970年代と1980年代には、構造化プログラミング パラダイムが好まれ、goto文の使用は衰退し、gotoは保守不可能なスパゲッティコードにつながると批判された。GNU Pascalコーディング標準などの一部のプログラミングスタイルのコーディング標準では、goto文の使用は推奨されていない。[23]ボーム–ヤコピニの証明（1966年）では、ソフトウェア開発に構造化プログラミングを採用するかどうかの問題が解決されなかったが、その理由の1つは、その適用には追加のローカル変数の導入が必要になるため、構造化プログラミングの構築によってプログラムが改善されるよりもわかりにくくなる可能性が高いためである。[24]しかし、これはコンピュータ科学者、教育者、言語設計者、アプリケーションプログラマーの間で活発な議論を引き起こし、かつては広く使われていたgotoの使用から、ゆっくりと、しかし着実に移行していきました。gotoに対する最も有名な批判は、おそらくエドガー・ダイクストラが1968年に書いた「go-to文は有害であると考えられる」という書簡でしょう。[22]この書簡の中で、ダイクストラは、制限のないgoto文はプログラム（特にループを含むもの）の正しさの解析と検証を複雑にするため、高水準言語から廃止されるべきだと主張しました。[25]この書簡自体が議論を引き起こし、 1987年3月にCommunications of the ACM (CACM)に送られた「『GOTOは有害であると考えられる』は有害であると考えられる」という書簡[26]や、ダイクストラの「やや残念な書簡について」[27]を含む他の人々からの返信も続きました。

別の観点としては、ドナルド・クヌースの『Structured Programming with go to Statements』が挙げられます。この本では、多くの一般的なプログラミングタスクを分析し、そのうちのいくつかではgotoが最適な言語構造であると結論付けています。[28] 『The C Programming Language』の中で、ブライアン・カーニハンとデニス・リッチーはgotoが「際限なく悪用される可能性がある」と警告していますが、関数終了時のエラーハンドラやループからの複数レベルのブレークに使用できる可能性も示唆しています。[29]これらの2つのパターンは、その後のC言語に関する他の著者による多数の書籍にも見られます。[30] [31] [32] [33] 2007年の入門書では、エラー処理パターンは「C言語に組み込まれた例外処理の欠如」を回避する方法であると述べられています。[30] Linuxカーネルの設計者でプログラマーのリーナス・トーバルズや、ソフトウェアエンジニアで本の著者でもあるスティーブ・マッコーネルなどの他のプログラマーもダイクストラの見解に反対しており、gotoはプログラムの速度、サイズ、コードの明瞭性を向上させる便利な言語機能になり得るが、それは同様に賢明なプログラマーが賢明な方法で使用する場合に限られると主張している。[34] [35]コンピュータサイエンスの教授ジョン・レーガーによると、2013年にはLinuxカーネルコードに約10万回のgotoのインスタンスがあった。[36]

他の学者たちはより極端な見解を取り、ループの途中からやのような命令を実行することさえも、ベーム＝ヤコピニの結果には必要ないので悪い習慣だと主張し、ループは単一の出口点を持つべきだと主張した。break[ 37]例えば、ベルトラン・マイヤーは2009年の教科書で、やのような命令は「羊の皮をかぶった古いgotoに過ぎない」と書いている。[ 38]しかし、ベーム＝ヤコピニの結果をわずかに修正した形では、ループからの複数レベルのbreakが許される限り、構造化プログラミングで追加の変数を避けることができる。[39] C言語など、キーワードによる複数レベルのbreakが許可されていない言語もあるため、そのような状況ではgotoを使うようにプログラマーに勧める教科書もある。[33] MISRA C 2004標準では、goto、、および複数のand文が禁止されている。[40] 2012年版のMISRA C標準では、gotoの禁止が「必須」から「推奨」に格下げされました。2012年版には、gotoによる後方ジャンプは禁止するが前方ジャンプは禁止しないという追加の必須ルールがあります。[41] [42]returnbreakcontinuebreakcontinuereturnbreak

FORTRANは1978年に構造化プログラミング構造を導入し、その後の改訂で、goto文の使用に関する比較的緩い意味規則が厳格化されました。プログラマがgoto文を使って実行中のDOループから抜け出し、再びループに入ることができる「拡張範囲」は1978年に言語から削除され、[43]、1995年までに計算型goto文や代入型goto文を含むいくつかの形式のFortran goto文が削除されました。[44] JavaやPython など、広く使用されている現代のプログラミング言語の中にはgoto文を持たないものもありますが、ほとんどの言語では選択範囲から抜け出す、あるいは反復処理の次のステップから抜け出す、あるいは次のステップに進むための何らかの手段が提供されています。コードの制御フローを乱すことは望ましくないという考え方は、一部のプログラミング言語の設計に見られるように、例えばAda [45]では山括弧を用いてラベル定義を視覚的に強調しています。

comp.lang.c FAQリスト[46]のエントリ17.10では、goto useの問題について次のように述べられています。

プログラミングスタイルは、ライティングスタイルと同様に、ある種の芸術であり、硬直したルールで体系化することはできません。しかし、スタイルに関する議論は往々にしてそうしたルールにのみ集中しているように見えます。goto文の場合、goto文を無制限に使用すると、メンテナンスが困難なスパゲッティコードにすぐに繋がってしまうことが長年指摘されてきました。しかし、goto文を単純に、無意識に禁止したからといって、必ずしもすぐに美しいプログラミングにつながるわけではありません。構造化されていないプログラマーは、goto文を一切使わずにビザンチン構造を構築してしまう可能性があります（代わりに、奇妙にネストされたループやブール制御変数を使用するかもしれません）。多くのプログラマーは穏健なスタンスをとっています。goto文は通常は避けるべきですが、必要に応じて、制約が厳しいいくつかの状況では許容されます。例えば、複数レベルのbreak文を使用する場合、switch文内で共通のアクションをまとめる場合、複数のエラーを返す関数でクリーンアップタスクを集中させる場合などです。 （…）特定の構造を盲目的に避けたり、ルールを理解せずに従ったりすることは、ルールが本来避けるべき問題と同じくらい多くの問題を引き起こす可能性があります。さらに、プログラミングスタイルに関する多くの意見は、まさに意見に過ぎません。それらは力強く主張され、強い思い入れがあり、一見確固とした証拠や議論によって裏付けられているかもしれませんが、反対意見も同様に強く感じられ、支持され、議論されている可能性があります。「スタイル戦争」に巻き込まれるのは大抵無駄です。なぜなら、特定の問題に関しては、反対意見が決して同意できなかったり、意見の相違を認めたり、議論をやめたりできないように見えるからです。

より受け入れられるパターン

goto の使用は全体的に減少していますが、goto がプログラムロジックを表現するのに適した方法となる状況もあります。goto を使わずにロジックを表現することは可能ですが、同等のコードはより長く、理解しにくくなります。goto が許容される可能性が高い状況としては、以下のものがあります。[34] [47]

  • エラー処理、特にリソースの解放などのクリーンアップコード。[30] [33] [48] [49] [50]
  • コードの重複を減らす。[34] [47]
  • 言語で直接サポートされていない場合は、複数レベルのbreakとcontinueを実装する。これはC言語では一般的な慣用句である。 [33] Javaはgotoキーワードを予約しているものの、実際には実装していない。代わりに、Javaはラベル付きのbreak文とcontinue文を実装している。[51] Javaのドキュメントによると、複数レベルのbreakにgoto文を使用するのは、C言語におけるgoto文の最も一般的な使用法（90%）であった。[52] Javaは、goto文を禁止する代わりに複数レベルのbreakを提供するというこのアプローチを採用した最初の言語ではない。この点では、 BLISSプログラミング言語（より正確にはBLISS-11バージョン）がJavaに先行していた。[53]
  • 追加のループの導入によって制御フローに誤った影響を与える可能性がある場合に、単一レベルのbreak文またはcontinue（retry）文の代替として使用できます。この方法はNetBSDコードで確認されています。[48]
  • AlgolやPL/Iなどの言語でスタックをポップします。
  • ビデオゲームの対話システムなど、線形に動作する特殊なスクリプト言語。[54]

これらの用法はCでは比較的一般的ですが、C++やより高水準の機能を備えた他の言語ではあまり一般的ではありません。[50]しかし、関数内で例外をスローしたりキャッチしたりすることは、一部の言語では非常に非効率になることがあります。その代表例がObjective-Cで、gotoの方がはるかに高速な代替手段となります。[55]

gotoのもう一つの用途は、適切にファクタリングされていないレガシーコードを修正することです。gotoの使用を避けるには、大規模なリファクタリングやコードの重複が必要になります。例えば、特定のコードのみに関心のある大規模な関数がある場合、gotoを使用すると、関数の他の部分を変更することなく、関連するコードのみにジャンプしたり、関連するコードからジャンプしたりできます。この用法はコードスメル[ 56]と見なされますが、時折使用されます。

代替案

構造化プログラミング

構造化プログラミング運動は、次のような制御構造を言語に 導入することで、goto ステートメントの必要性と使用を排除することを目指しました 。

選択
条件文（if-then-else）やswitch文など
反復
for ループ、while ループ、Do while ループなどのループ ステートメント。

これらの新しい言語メカニズムは、以前はgoto文を使用して記述されていた同等の制御フローを置き換えました。switch文は、ジャンプ先の命令が動的（条件付き）に決定される計算型goto文に代わるものです。

特定の条件下では、レガシープログラムのローカルgoto文を複数レベルのループexit文に置き換えることで削除することが可能です。[57]

例外処理

実際には、構造化プログラミングの基本的な 3 つの構造テンプレートを厳密に順守すると、構造化単位を途中で終了することができないため、高度にネストされたコードが生成され、すべての可能性のある条件を処理するために非常に複雑なプログラム状態データの組み合わせが爆発的に増加します。

一般的に採用されている解決策は 2 つあります。構造化単位を途中で終了する方法と、より一般的には例外処理です。これらは両方とも構造を上っていき、囲んでいるブロックまたは関数に制御を返しますが、任意のコード位置にジャンプすることはありません。これらは、非終端位置での return ステートメントの使用に似ています。早期終了のため厳密には構造化されていませんが、構造化プログラミングの制約がわずかに緩和されています。C では、breakおよびcontinueを使用すると、余分な while または if ステートメントを必要とせずに、ループを終了したり、次の反復に進んだりすることができます。一部の言語では、複数レベルのブレークも可能です。例外的な状況を処理するために、Java の --などの特殊な例外処理構造が追加されました。trycatchfinally

throw-catch例外処理メカニズムも、gotoが悪用されるのと同じように、簡単に悪用されて非透過的な制御構造を作成する可能性があります。[58]

末尾呼び出し

1977年にシアトルで開催されたACMカンファレンスで発表された論文の中で、ガイ・L・スティールはgotoと構造化プログラミングに関する議論を要約し、手続きの末尾位置における手続き呼び出しは、呼び出された手続きへの制御の直接的な移行として最も最適に扱うことができ、通常は不要なスタック操作操作を排除できると指摘した。[59]このような「末尾呼び出し」は、手続き呼び出しが至る所で見られる言語であるLispでは非常に一般的であるため、この形式の最適化は、他の言語で使用されるgotoと比較して、手続き呼び出しのコストを大幅に削減する。スティールは、手続き呼び出しの実装が不十分なために、gotoは手続き呼び出しに比べて安価であるという人為的な認識が生まれていると主張した。さらにスティールは、「一般的に、手続き呼び出しは、パラメータも渡すgoto文と考えるのが適切であり、機械語のJUMP命令として統一的にコード化できる」とし、機械語のスタック操作命令は「最適化とみなされる（逆ではなく！）」と主張した。[59]スティールは、Lispで最適化された数値アルゴリズムは、当時入手可能な商用Fortranコンパイラで生成されたコードよりも高速に実行できるという証拠を挙げた。これは、Lispの手続き呼び出しのコストがはるかに低いためである。スティールがジェラルド・ジェイ・サスマンと共同で開発したLisp方言であるSchemeでは、末尾呼び出しの最適化が必須となっている。[60]

Steele の論文は、少なくとも MIT で実践されていたものにおいては、コンピュータ サイエンスに目新しいことをあまり導入していなかったが、手続き呼び出し最適化の可能性を明らかにした。これにより、手続きのモジュール化を促進する特性が、複雑な内部制御構造と広範な状態データを持つ大規模モノリシック手続きという当時の一般的なコーディング習慣に代わる、より信頼性の高いものとなった。特に、Steele が論じた末尾呼び出し最適化により、手続きは単一の末尾再帰(同じ関数を呼び出す末尾再帰) による反復処理を実装する信頼性の高い方法になった。さらに、末尾呼び出し最適化では、末尾呼び出しを前提として、無制限の深さの相互再帰が可能になる。これにより、通常は goto 文で実現される有限状態マシンなどの制御の移行が可能になる。

コルーチン

コルーチンは、構造化プログラミングを大幅に緩和したものであり、複数の終了ポイント（末尾以外の位置での return など）だけでなく、goto 文と同様に複数のエントリ ポイントも許可します。コルーチンは goto よりも制限が厳しく、コード内の任意の位置にジャンプするのではなく、現在実行中のコルーチンを指定された位置（yield の後に継続）でのみ再開できます。コルーチンの制限された形式はジェネレータです。さらに制限されているのは、クロージャです。クロージャは、状態（静的変数経由）は維持しますが、実行位置は維持しない関数です。状態変数と構造化制御の組み合わせ、特に全体的な switch 文を使用すると、関数は後続の呼び出しで任意の位置から実行を再開できます。これは、コルーチンがない場合に goto に代わる構造化された代替手段です。これは、たとえば C でよく使用されるイディオムです。

継続

継続は、プログラム内の任意のポイントからマークされたポイントに制御を移すという点で goto に似ています。継続は、ほとんどの構造化プログラミング言語の goto ではできない、現在の関数の外に制御を移すことができるという点で goto よりも柔軟です。ローカル変数と関数の引数を格納するためのスタック フレームを維持する言語実装では、継続を実行すると、ジャンプに加えて、プログラムの呼び出しスタックの調整が必要になります。Cプログラミング言語のlongjmp関数は、現在のコンテキストから周囲のコンテキストに脱出するために使用できる脱出継続の例です。Common Lisp のGO 演算子も、構文がレキシカル スコープであるにもかかわらず、このスタック巻き戻しプロパティを持ちます。これは、ジャンプ先のラベルをクロージャから参照できるためです。

Schemeでは、継続によって制御を外側のコンテキストから内側のコンテキストに移動することができます。これにより、コルーチンや協調型マルチタスクなどの制御構造を記述できるようになります。[60]

参照

  • COMEFROM  – プログラミング言語の制御フロー文。gotoの反対語。
  • GOSUB  – プログラミング言語ファミリー
  • スイッチ文 – 値に基づいて制御を分岐するプログラミング文
  • 非構造化プログラミング – 構造化プログラミングに先立つプログラミングパラダイム

注記

  1. ^ ワット＆フィンドレー 2004.
  2. ^ Kernighan & Ritchie 1988、p.224、A9.6 ジャンプステートメント。
  3. ^ ただし、 setjmp/longjmp関数を使用すると、呼び出しチェーン内でのジャンプは可能です。
  4. ^ ワーグナー 2021.
  5. ^ 「GoTo ステートメント - Visual Basic | Microsoft Learn」。Microsoft Learn . 2021年9月15日. 2023年9月25日閲覧。
  6. ^ Gosling et al. (2005) C言語やC++とは異なり、Javaプログラミング言語にはgoto文がありません。識別子文ラベルは、ラベル付き文内の任意の場所に出現するbreak文（§14.15）またはcontinue文（§14.16）で使用されます。キーワードconstとgotoは予約語ですが、現在は使用されていません。これにより、JavaコンパイラはこれらのC++キーワードがプログラム内で誤って出現した場合に、より適切なエラーメッセージを生成できるようになります。
  7. ^ Hindle 2004より。
  8. ^ ab Noack et al. 2015.
  9. ^ PHPマニュアル 2021.
  10. ^ Galler 1962、26–28、197、211。
  11. ^ は 、 iが 0 より小さい、0 と等しい、または 0 より大きい場合、プログラムがラベル 20、30、または 40 にジャンプすることを意味します。
  12. ^ Lahey Computer Systems, Inc 2004.
  13. ^ マイクロソフト 2021.
  14. ^ ヴェーア 1997.
  15. ^ IBM ドキュメンテーション 2021 の z/OS 2.5.0。
  16. ^ ab GCC、GNU コンパイラ コレクション 2021。
  17. ^ フロンザック＆ルバーズ 1974年、226ページ。
  18. ^ ヴァン・タッセル 2004年。
  19. ^ Perl構文マニュアル 2021。
  20. ^ Java 2009 の goto。
  21. ^ セクストン 2012.
  22. ^ ダイクストラ 1968より。
  23. ^ GNU Pascal 開発チーム 2005、5.1 さまざまな Pascal プログラミングのヒント。
  24. ^ ラウデン＆ランバート 2012.
  25. ^ 「goto ステートメントを無制限に使用すると、プロセスの進行状況を記述するための意味のある座標セットを見つけることが非常に困難になります。…現状の 'go to' ステートメントはあまりにも原始的であり、プログラムを台無しにする原因になりすぎています。」
  26. ^ ルビン 1987.
  27. ^ ダイクストラ、エドガー・W.「やや残念な書簡について（EWD-1009）」（PDF） EWダイクストラ・アーカイブ。テキサス大学オースティン校アメリカ史センター。（転写）（1987年5月）
  28. ^ クヌース 1974.
  29. ^ Kernighan & Ritchie 1988、pp. 65–66、3.8 Gotoとラベル。
  30. ^ abc Vine 2007、262ページ。
  31. ^ ガイスラー 2011.
  32. ^ プラタ 2013.
  33. ^ abcd サニ＆クメリク 1995.
  34. ^ abc アンドリュース 2003.
  35. ^ マコーネル 2004.
  36. ^ レゲール 2013.
  37. ^ ロバーツ 1995.
  38. ^ マイヤー 2009.
  39. ^ コーゼン＆ツェン 2008.
  40. ^ Stack Overflow の質問 2012。
  41. ^ ピッチフォード＆タップ 2013.
  42. ^ ウィリアムズ 2013.
  43. ^ ANSI X3.9-1978. 米国国家規格 - プログラミング言語 FORTRAN. 米国規格協会。ISO 1539-1980、通称FORTRAN 77とも呼ばれる。
  44. ^ ISO/IEC 1539-1:1997. 情報技術 – プログラミング言語 – Fortran – パート1：基本言語。非公式にはFortran 95として知られています。この規格にはさらに2つのパートがあります。パート1はANSIによって正式に採用されています。
  45. ^ バーンズ 2006.
  46. ^ サミット 1995。
  47. ^ ab Torvalds 2016.
  48. ^ Spinellis 2003より。
  49. ^ Cozens 2004より。
  50. ^ Allain 2019による。
  51. ^ Javaチュートリアル 2012。
  52. ^ ゴスリング＆マクギルトン 1996.
  53. ^ ブレンダー、2002 年、960–965 ページ。
  54. ^ Hoad, Nathan (2022年7月28日). “nathanhoad/godot_dialogue_manager”. GitHub . 2023年2月3日閲覧。
  55. ^ チズナル 2012.
  56. ^ コンティエリ 2021年。
  57. ^ ラムショー 1988.
  58. ^ ジーダースレーベン 2006年。
  59. ^ スティール 1977より。
  60. ^ ケルシー、クリンガー、リース 1998より。

参考文献

  • Allain, Alex (2019). 「C言語でGoto関数を使うべきタイミング」 . 2021年11月14日閲覧。
  • アンドリュース、ジェレミー (2003年1月13日). 「Linux: カーネルコード内での goto の使用」. 2005年11月28日時点のオリジナルよりアーカイブ。2021年11月14日閲覧。
  • ブレンダー、ロナルド・F. (2002). 「BLISSプログラミング言語：歴史」(PDF) .ソフトウェア：実践と経験. 32 (10): 955– 981. doi :10.1002/spe.470. S2CID  45466625.
  • チズナル、デイビッド (2012). 『Objective-C フレーズブック』. アディソン・ウェズリー・プロフェッショナル. p. 249. ISBN 978-0-321-81375-6。
  • コンティエーリ、マキシ（2021-11-02）。 「コードスメル100 - GoTo」。Maximiliano Contieri - ソフトウェア デザイン。2021年11月14日閲覧。
  • サイモン・コーゼンズ (2004年4月16日). 「gotoの効果的な使い方」サイモン・コーゼンズとヘンリエッタ・コーゼンズ. 2011年3月19日時点のオリジナルよりアーカイブ。
  • Fronczak, Edward J.; Lubbers, Clark E. (1974年9月). MTS, ミシガン端末システム. ミシガン大学コンピューティングセンター. UOM:39015034770076.
  • Galler, Bernard A. (1962年1月1日). 『コンピュータ言語』（PDF） . McGraw-Hill.
  • GCC、GNUコンパイラコレクション (2021). 「ラベルを値として使う - GNUコンパイラコレクション (GCC) の使用」. Gcc.gnu.org . 2021年11月13日閲覧。
  • ガイスラー、サンドラ (2011). 『C オールインワン・デスクリファレンス・フォー・ダミーズ』 ジョン・ワイリー・アンド・サンズ. pp.  217– 220. ISBN 978-1-118-05424-6。
  • GNU Pascal開発チーム(2005). 「GNU Pascalコーディング標準」. www.gnu-pascal.de . フリーソフトウェア財団. 2021年11月10日閲覧。
  • Gosling, James、McGilton, Henry (1996年5月). 「Java言語環境」. Oracle.com . 2014年7月22日閲覧。
  • GOTO for Java (2009年7月6日). 「GOTO for Java」. steik . 2012年6月15日時点のオリジナルよりアーカイブ。2012年4月28日閲覧。
  • Hindle, Richie (2004年4月1日). 「Python用goto」. Entrian Solutions . 英国ハートフォード: Entrian Solutions Ltd. 2021年11月10日閲覧。
  • Javaチュートリアル (2012年2月28日). 「分岐文（Javaチュートリアル > Java言語の学習 > 言語の基礎）」. Docs.oracle.com . 2021年11月10日閲覧。
  • Kelsey, R.; Clinger, W.; Rees, J.; et al. (1998年8月). 「アルゴリズム言語Schemeに関する改訂報告書」 .高階および記号計算. 11 (1): 7– 105. doi :10.1023/A:1010051815785. S2CID  14069423.
  • Knuth, Donald (1974). 「go to 文を用いた構造化プログラミング」(PDF) . Computing Surveys . 6 (4): 261– 301. CiteSeerX  10.1.1.103.6084 . doi :10.1145/356635.356640. S2CID  207630080. オリジナル(PDF)から2017年7月17日にアーカイブ. 2017年1月26日閲覧.
  • Kozen, Dexter ; Tseng, Wei-Lung Dustin (2008年7月). 「Böhm-Jacopiniの定理は命題的に偽である」(PDF) . Audebaud, Philippe; Paulin-Mohring, Christine (編).プログラム構築の数学. 第9回国際会議MPC 2008. コンピュータサイエンス講義ノート. 第5133巻. マルセイユ, フランス. pp. 177-192. CiteSeerX  10.1.1.218.9241 . doi :10.1007/978-3-540-70594-9_11. ISBN 978-3-540-70593-2。
  • Lahey Computer Systems, Inc (2004). 「Computed GOTO Statement (obsolescent)」. Lahey Computer Systems, Inc. 2016年5月26日時点のオリジナルよりアーカイブ。2021年11月10日閲覧。
  • ラウデン、ケネス・C.; ランバート、ケネス・A. (2012). 『プログラミング言語：原則と実践』 センゲージ・ラーニング. p. 422. ISBN 978-1-111-52941-3。
  • マコーネル、スティーブ（2004年12月）『Code Complete：ソフトウェア構築実践ハンドブック 第2版』（第2版）Microsoft Press. ISBN 978-0735619678。
  • マイヤー、バートランド (2009). 『Touch of Class: Learning to Program Well with Objects and Contracts』 Springer Science & Business Media. p. 189. ISBN 978-3-540-92144-8。
  • Microsoft (2021). 「'On GoTo' および 'On GoSub' ステートメントはサポートされなくなりました」. Microsoft . 2021年11月10日閲覧。
  • Noack, Sebastian; Blank, Douglas; Grainger, Thomas; spacewander (2015年9月19日). 「snoack/python-goto: Pythonでgotoを有効にするためにバイトコードを書き換える関数デコレータ」. GitHub . 2021年11月10日閲覧。
  • Perl構文マニュアル (2021). Goto (レポート) . 2021年11月14日閲覧.
  • PHPマニュアル (2021). 「goto」. PHP . 2021年11月13日閲覧。
  • Pitchford, Mark; Tapp, Chris (2013年2月25日). 「MISRA C:2012：変更すべき十分な理由」. Electronic Design . 2014年7月22日閲覧.
  • プラタ、スティーブン (2013)。Cプライマープラス。アディソン・ウェスリー。ページ 287–289。ISBN​​ 978-0-13-343238-1。
  • ラムショー, L. (1988). 「プログラム構造を維持しながらgo to文を削除する」. Journal of the ACM . 35 (4): 893– 920. doi : 10.1145/48014.48021 . S2CID  31001665.
  • Regehr, John (2013年2月4日). 「システムコードにおけるgoto文の使用 - 学術界への組み込み」. blog.regehr.org .
  • Roberts, Eric S. (1995年3月). 「ループ終了と構造化プログラミング：議論の再開」. ACM SIGCSE Bulletin . 27 (1): 268– 272. doi : 10.1145/199691.199815 .
  • Rubin, Frank (1987年3月). 「"GOTO は有害と考えられる" 有害と考えられる」(PDF) . Communications of the ACM . 30 (3): 195– 196. doi :10.1145/214748.315722. S2CID  6853038. 2009年3月20日時点のオリジナル(PDF)からアーカイブ。
  • サーニ、サルタージ。ボブ・シメリック (1995)。 C. Silicon Press でのソフトウェア開発。 p. 135.ISBN​ 978-0-929306-16-2。
  • Sexton, Alex (2012). 「The Summer of Goto | Official Home of Goto.js」. 2015年10月25日時点のオリジナルよりアーカイブ。
  • ジーダースレーベン、ヨハネス (2006). 「エラーと例外 - 権利と義務」. クリストフ・ドニー編. 『例外処理技術の高度なトピック』. シュプリンガー・サイエンス＆ビジネス・メディア. p. 277. ISBN 978-3-540-37443-5。
  • スピネリス、ディオミディス（2003年5月27日）『コードリーディング：オープンソースの視点』アディソン・ウェズリー・プロフェッショナル、  43～ 44ページ。ISBN 978-0-672-33370-5。
  • Stack Overflow の質問 (2012年6月11日)。「なぜ「continue」はMISRA C:2004でC違反とみなされるのか？」 Stack Overflow 。 2021年11月10日閲覧。
  • Steele, Guy Lewis (1977年1月). 「『高価な手続き呼び出し』という神話の打破、あるいは手続き呼び出しの実装が有害と考えられること、あるいはLAMBDA」. 1977年ACM年次会議議事録. pp.  153– 162. doi : 10.1145/800179.810196 . ISBN 9781450323086. S2CID  9807843。
  • Stroustrup、Bjarne (2012-01-09)。 「1 日目基調講演 - Bjarne Stroustrup: C++11 スタイル | GoingNative 2012 | Channel 9」。 Channel9.msdn.com 。2021年11月10日閲覧。
  • Summit, Steve (1995). 「comp.lang.c FAQリスト · 質問17.10」. C-faq.com . 2021年11月10日閲覧。
  • Goプログラミング言語仕様（2021年7月26日）。「Goプログラミング言語仕様 - Goプログラミング言語」
  • Torvalds, Linus (2016). 「Linuxカーネルコーディングスタイル」. Linuxカーネルのドキュメント. 2021年11月10日閲覧。
  • Van Tassel, Dennie (2004年7月8日). 「プログラミング言語におけるラベルの歴史」 . 2011年1月4日閲覧。
  • ヴァイン、マイケル・A. (2007). 『Cプログラミング入門』センゲージラーニング. ISBN 978-1-59863-634-5。
  • Wagner, Bill (2021). 「goto ステートメント - C# リファレンス」. docs.microsoft.com . 2021年11月9日閲覧。
  • ワット、デイビッド・アンソニー、フィンドレー、ウィリアム（2004年）『プログラミング言語設計コンセプト』ジョン・ワイリー・アンド・サンズ、p.228、ISBN 978-0-470-85320-7。
  • Wehr, Jason (1997). 「Go to (assigned)」. www.personal.psu.edu/jhm/f90/201.html . 2021年11月13日閲覧。
  • ウィリアムズ、トム (2013年3月). 「C言語のチェックルール：信頼性と安全性の確保」RTCマガジン22 ( 3): 12– 15 . 2021年11月10日閲覧。
  • IBMドキュメント（2021年）のz/OS 2.5.0。「計算型goto文（IBM拡張）」。IBM 。2021年11月13日閲覧。この文書では、CおよびC++プログラミング言語の構文、セマンティクス、およびIBM z/OS XL C/C++実装について説明します。汎用CまたはC++標準リファレンスについては、cppreference.comをご覧ください。{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)