Cでgotoを使わない理由を考察するスレ goto loop2;

why?

前スレ
Cでgotoを使わない理由を考察するスレ
http://pc.2ch.net/test/read.cgi/prog/1053627318/

2 なのか？

3

#if 0

#endif

977 名前：828[sage] 投稿日：03/11/30 22:36
勝手に終わらないで欲しかったのだが。

＞「議論をするつもりはない」とのお考えだと判断して良いですかね。
つもりがなかったらそもそもこのスレに書き込んでいないわけですが。

＞私はあなたの言う「違反者」ではありませんよ。
ですね。はじめから法の外にいるという立場のようですから。

＞構造化プログラミングは万能かも知れないですが、
＞全ての場合において最適解であるかというと、私は懐疑的です。
だから、いいか、悪いかではなくて
慣例、習慣、法律などの決まりごとにそって生きるのが人間で、その方が生き易い。
多少融通が効かない事はあるだろうけど、世の中の全ての人が大岡越前になれるわけではない
(と私は思っているのですが、あなたに言わせると「ご愁傷様」らしいですね。
あなたは世界中の裁判官が大岡裁きができるとお考えですか？)

でもまあ、私の経験だと、これくらいやり込められるとほとんどのナナシは
自作自演やら荒らしやらのアンフェアな方法に出る２ちゃんで、
正々堂々と意見と意見の戦いで通された事は感謝と尊敬の念を感じました。
後輩から教わった話ですが、年寄りというのは
若者に理解されない話を頑なにすることで、若者の中の新しい文化への
情熱や信念を強固にさせる役割もあるんだそうです。

いつまでも頑なな頑固ジジイであれ！>>124

void main();

>>1
おまえウザイんだよ。
もうこんな糞スレ立てんなｳﾞｫｹ
ダイクストラがgoto使わない理由を証明しているなら
こんなスレｲﾗﾈーだろカスが

とっとと削除依頼出して来い！

ぐだぐだ言わずにgotoを使わなければかけないコードを示せば議論は終わる。

>>8
「gotoを使わなければかけないコード」
は存在しないと数学的に証明されてるよ。

>>8
誰かが議論していたとでも言うような口ぶりだな。

まちがえた！
http://pc.2ch.net/test/read.cgi/prog/1053627318/991-994n
（誤）Dim lCnt As Long, sLoop As String, bQuot As Boolean, sNewSource As String
↓
（正）Dim lCnt As Long, sLoop As String, bQuot As Boolean

goto使ったらﾀｲｰﾎというわけではないが、
「やだー あのひとgoto使ってる〜 ありえな〜いw」って感じか？

つか、C使ってる時点で
「やだー あのプロジェクトC使ってる〜 ありえな〜いw」
だろう。

もうgotoは秋田のでファイル/関数/データ名の名前の付け方の
ＭＳによる謝罪と賠償を求めるのが面白いと思うのですが。

>>13
それは確かにw

>>13
おまえは、ただのアプリ屋だろゴミは氏ね！

>>16
うむ、>>13ではないが、日本のシェアを圧倒する国産コンパイラ、国産OSを頼む。

>>16
できればCPUから頼む。

Σ・・・MSの配下に成り下がったTRON・・・
もう、だめぽ。

Y氏 好循環　　I氏 悪循環　　（日本）
　（健康体）　　（喘息）

1.（神が喘息であるかないかを決める）
　　Y　　　　　　　　I
2.喘息でない人　　喘息の人は
は体力がある　　　体力がない
Y I
3.　　　　　　　　行動力、
　　　　　　　　　五感（嗅覚）が鈍り感性が変化
　　　　　　　　　する
　　Y　　　　　　　　I
4.神は異常な感性の人間は本来人に迷惑をかけるから外に出てはいけないと思っている。
Y I
5.変化なし　　　　アトピーになる
Y I
6.正常な感性　　　外に出なくなりさらに異常な感　　　　　　　　　性になる
Y I
7.正常な人間 　　 異常な人間（レッテル）

Y I
8. 死
　　Y　　　　　　　　I
9.　　　　　　来世
Y I
10.神は異常な人間は人に迷惑をかけるので行動を抑制する必要がある
Y I
11.神は異常な人間は人に迷惑をかけるので行動を抑制する必要があると思っている。
Y I
12.神が喘息であるかないかを決める
　　Y　　　　　　　　I
13.喘息でない　　　喘息である
　　Y　　　　　　　　I
　　　　　1.に戻る

アトピー性皮膚炎の治し方

行動力=ガッツ=体力

アトピー性皮膚炎の患者は、
感覚の鈍い人間が多い。
それはなぜか。
幼少期喘息になるから、
体力がつかないため、
五感が弱るからである。
解決方法は、
五感を強くしてやればいい。
体力をつけることですぐに五感が正常になり、
行動力も湧くのである。
五感が正常になり、体力もつけば、
アトピー性皮膚炎も不思議と消えることが多い。

>>22
それが本当なら本にして売り出せよ。
大もうけできるぞ！

そういえば、世の中でgotoが使われなくなったのと
アトピー性皮膚炎が流行りだしたのは同時だな・・

>>24
そうだったのか！やはり人間的にはgotoを平気で使えるような
世界情勢が一番だとゆう漏れの学説が正しかったんだなｗ

中級者レベルぐらいだとgoto使う以上にベターなコーディングを思いつかない
ことも多いと思うよ。で、その中級者が職場では一番レベルが高いということも
多いので、goto使わないベストなコーディング方法を教えることが出来る人が
いない。

goto使うときってこういうときでしょ。

なに言ってんだコイツ？

そっか。アトピーには goto 療法が効くのか。
おい、だれか学会に発表しろ。ノーベル賞ものだぞ！

アトピー以外にインポを初めとしてあらゆる性病には
有効らしいぞ。

>>22
なんだか本当に、それで直りそうな気がするｗ

とりあえず、goto使うやつにアトピーはいないって事か？

>>31
チョツト違うな、gotoも使えないゴミはアトピーになるんだよ！！！

>>26
いい加減なこと言うな。

多重ループから抜けるときgoto以上に分かりやすいものがあれば教えてください

>>34
ラベルbreak

違った、無い。

>>34
そんなちょこざいな便利さなど問題じゃないよ。
goto使えば、逆に多重ループの内側に飛び込めたりもするわけで、
コーディング規約に、gotoのこの使い方は良いとかこれは悪いとか、
いろいろ規制を設けないといけなくなる。めんどいでしょ？
要はイリーガルな使用ができるステートメントは省くべきということでは？

>>34
多重ループなんか作るな。再考しろ

>>37
規約には「ループからの脱出時のみ可」とでも書けばいいんじゃないですか？

>>37
×要はイリーガルな使用ができるステートメントは省くべきということでは？
○要は解析性が極端に低下する使用法が可能なステートメントは省くべきということでは？
「イリーガル」という形容は間違いだろう。

>>34 return

>41
同一関数内では利用できない

>>40
100行以上などの長大な関数がかけてしまうC言語も使用を避けるべきですな！

>>43
関数長すぎるとエラー出す言語ってあるの？

VCでは関数が長すぎると、IDEがスクロールしにくくなる。

>>44
無いと思うよ。ネストの上限が５っていう言語なら見たことあるけど。

>>44
goto使うとエラー出るの？

>>47
おまえの頭がエラーだわなw

>>37
そうだな、よし！
switch 〜 case も危険だから使用禁止にするぞ！

　　switch (id) {
　　　　int i=0, j=0;
　　　　for (i=0; i<n; i++)
　　　　　　for (j=0; j<m; j++) {
　　　　　　　　：
　　　　　　　　：
　　case 0:
　　　　　　　　：
　　　　　　　　：
　　　　　　}
　　case 1:
　　　　：
　　　　：
　　}

>>49
C言語では、idなどという曖昧な変数名を使用できてしまい解析性が著しく低下して
しまうので、変数の使用はそもそも禁止されてるんじゃないかな？
だって、いろいろ規制を設けないといけなくてめんどくさい場合は、禁止するらしいから。

まぁ、結果として、switchも使えないから安心してちょ。

>>50
実に論旨不明瞭だな。
＞idなどという曖昧な変数名を使用できてしまい解析性が著しく低下してしまうので
「idという変数名を使用することが、解析性が著しく低下する原因」というわけじゃないぞ
そんなことで解析性が低下すると思っているのは、すでに十分に解析性が低い証拠だ。

>>51
いや、だって id ってグローバル変数ですよ!?

>>51
ええと、
『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、「解析性が著しく
　低下する原因」となる可能性は無い』
という主張？

あぁ、しかも>>51には、変数宣言以外にも、「解析性が著しく低下する原因」となる
C言語の特性が存在することが示唆されているな…。なんか、どんどん使える範囲が
狭まっていく…

>>37
おまえのところは、コードのレビューもせずに
個々のPGが勝手にコード書いてるのか？

っていうか、おまいら何で今時「Ｃ言語」の話題なんだ？
しかもいまさらgoto論なんて、時代錯誤もいいとこだな。
おまいらどうせ学生だろ？
いまどきＣやってる奴なんて、学校関係者ぐらいのもんだからな。
教育現場では頑なに UNIX + C だからなｗ

>56
おまいの発言が一番学生っぽいぞ。
それともよっぽどちんけな仕事しかしたことないのか？

>>57
チンカスで悪かったな！　この道程・モーほーお宅野郎！

>>58=>>56はチンカスらしい。
自分で言ってるぐらいだからな

>>52
グローバル変数は使用禁止だ。したがって命名は無関係だ。

>>53
＞『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、
＞「解析性が著しく低下する原因」となる可能性は無い』？
no

>>54
yes。自分でもそう思っているんだろ。
＞どんどん使える範囲が狭まっていく…
俺が「使用禁止にすべき」だと思うのは「グローバル変数」だけだけど。

でもC++ってグローバル定数とグローバル関数(API)だらけでぐちゃぐちゃだよね。
入力支援ない上に名前長すぎて覚えられないよ。
どうやって覚えてるの？語呂合わせ？

>>55
どうやったらそういう解釈になるのかさっぱりわからんが。。。
個々のPGがコーディング規約に沿って勝手にコード書いた後、
コードレビューしてるけど。

つまり、コードを評価する能力がないということか。

>>61
#C++は、ベンダによってライブラリセット（表現おかしい？）の方言が激しいって聞いたけど、
#その悩みはこの方言(ベンダ固有)が理由なのかなあ。
残念ながらここはｃがテーマなんだ。

>>60
グローバル変数使用禁止の理由教えて。俺は命名こそが大事だと思うんだが。
クラスだって巨大化すれば、メンバ変数もグローバルみたいなもんだよ(笑

>>61
STLもMFCもJAVAも、大概はヘルプやレファレンスやサンプル見ながら書くよ。
経験つめば次第に覚えるんだろうけど、他人が作った関数やクラスを利用
するんだから、全部を頭に入れるのは難しいよね。

>>49 >>50 >>52 がﾈﾀだってことに
いい加減気付いて欲しいなぁ…
因みに、>>49 みたいな事が出来るのはﾏｼﾞ。

ところでさ、「コードレビュー」ってどういうメリットがあるの？

>>65
でもさあ。コントロール用のIDC_HOGEとか、メニュー用のIDM_HOGEとか、
あれをなんでグローバル宣言するの？
1つの「物」についてあっちこっちにソースが分散して気持ち悪いよ。
取ったり付けたりする時に追跡しきれる？

グローバル変数はちょっとなあ・・・

どこででも直にアクセスできるのは値を保証できないからダメだろ。
絶対に値をロックしないし、どこからででもアクセスできなきゃ困るとかいう
珍しいパターンでもない限り出番がない。

あとクラスが巨大化するのは設計自体が間違っていると思われ

>>63
お宅の思考回路は理解できん。

>>60
> >>53
> ＞『どんな変数名(例えば意味づけの曖昧な変数名)を使っても、
> ＞「解析性が著しく低下する原因」となる可能性は無い』？
> no

変数の名づけ方によっては「解析性が著しく低下する原因」になり得るんだよね？
>>37, >>40の基準によるならば、変数宣言も省かなければならないのでは？という皮肉。
分かってると思うけど。

>>67
>でもさあ。コントロール用のIDC_HOGEとか、メニュー用のIDM_HOGEとか、
>あれをなんでグローバル宣言するの？
んなこたぁ MS に聞けば?
C++ の問題じゃない事くらい判らない?

定数は別に重ならなきゃOKだろ。じゃなきゃ、クラスもグローバル領域に宣言するのも
ダメということになる。
(分散オブジェクト環境みたいにいちいちネームサービスから探すか？)

>>66
個人が書いたコードをみんなで検証するとバグの早期発見とか、あと勉強にもなるよ。
>>67
コントロールIDはdefineだよ。IDは普通、一意の方が良いよね。
>>68
そこを命名によって、他モジュールから参照されるもの、
自モジュールのみから参照されるものというように分ければ良いんだよ。
もちろん変数だけでなく、関数もだけど。
そのへんきちんとすれば、Cでもオブジェクト指向的なコードが
書けると思う。

＞自モジュールのみから参照されるものというように分ければ良いんだよ。
要するにネームスペースやスコープ制御ができないCがクソということで。

>>70
yes
正確には「変数名」に限らず、（命名を行う）全ての識別子。

んじゃ、識別子の命名は解析性が著しく低下する原因にならなければ行ってOK、と。
ということは、「グローバル変数は確実に解析性が著しく低下する原因になる」ということですね？

>>73
>そのへんきちんとすれば、Cでもオブジェクト指向的なコードが
>書けると思う。
それは単なるカテゴライズであって
カプセル化ですらなく
まして OOP とは無関係。

読み易さ
　goto >>>>>>>>>> 関数ポインタ

無名関数とクロージャがほしい

>>73
モジュール内のグローバル変数(ファイルスコープ)の危険性は無視ですか？

>>74
まあ「ｃがクソ」と断じるのは勝手だが、
同様な理由で「C++がクソ」と言われる時期もいずれくると思っていたほうがいい。
いくらソフトウエア工学的理論が発達し、それをサポートする言語処理系が出来たとしても、
コンピュータがチューリングマシンの写像であることは当分変わらないのだから、
アセンブラレベルの理解が可能なｃをマスターしておくことは無駄ではないと思うが。

すでにC++はクソだってことは有名だが

なるほど〜。MSが悪いだけかあ。
言語仕様上そうしなきゃいけなかったのかと思った。

変数の副作用が怖ければ、関数型言語でも使ってろよ！
チューリング等価だぜ。

>>81
オブジェクトがどう振舞うかを記述する作業の中で、
アセンブラ云々を意識すると本質を見失う可能性あり。

>>76
yesだ。「くどいな」と感じたが、ちゃんと私見を書こう。
＞「グローバル変数は確実に解析性が著しく低下する原因になる」？
グローバル変数を使用することによってコーディング工数を低減させることは可能だ。
「解析性が著しく低下する」ことなしに。
しかしこれには「常人の短期記憶の容量を超えない範囲での使用」という条件がつく。
グローバル変数の使用を許可しても「常人の短期記憶の容量を超えない範囲での使用」
という条件を守られない場合の方が多い。これは「確実に解析性が著しく低下する」わけだ。
以上が解析性のみに限った話。
グローバル変数の使用は、解析性に限らず生産性／保守性全般に悪影響を及ぼす。

>>77
なんで？呼ばなければカプセル化と一緒でしょ？
private関数をコンパイル通る通らないに関係なく、外から呼ぼうとする人って
あまりいないよね。つまりはprivateだよ、publicだよって(命名規則で)印つけとけば
カプセル化はできる。

それでも外から呼んじゃうようなスキルの低い人にも絶対呼ばせないように、
OOPが登場してきたわけだ。コンパイラ様々。君はオブジェクト指向言語に
足向けて寝ないように(笑

>>85
そりゃそうだ。
クラス設計時にアセンブラレベルまで意識できる人間なぞ俺はしらん。また意識する必要もない。
＃設計作業群は多層構造だ。

>>87
情報の隠蔽用にクラスを作っているのなら、
オブジェクト指向の考え方を勉強することをお勧めする。

＞グローバル変数の使用は、解析性に限らず生産性／保守性全般に悪影響を及ぼす。
「常人の短期記憶の容量を超えない範囲での使用」をしている準グローバルな変数、
つまりインスタンス変数やクラス変数、モジュール変数(ファイルスコープ)などにも
全て問題があると？

まぁ、関数型言語の参照透過性の節には、それが破れることによる害悪が延々と
書いてあるわけだけども…

>>89
はじめはそれだけでも良いんじゃない？

>>30
goto文なんかばかり使ったコード読まされたら
アトピーになったような不快な気分を味わうってことだろ

>>89
誰もそんなことは言ってないし…

>>93
いや、87はOOPの意義を履き違えてるだろ。

gotoを解禁してからというもの、これは便利だなぁと実感するようになったけど、やばいかな。

>>92
つまり、goto否定原理主義者は、「先天的に」gotoに対するアレルギー体質を持っており、
gotoを使うことの可否に関わらず、必ず症状は出てしまうわけだ。
まぁ、ちょっと可哀想では有るがな…

>>87
ファイルスコープなら、staticにしとけば大抵自動的にガードできるだろ。

>>94
概念と実装を混同してない？

private/publicの区別をつけないとOOP出来ないわけでもなかろう。
(もちろん、アクセスの制限をつけるのは有用ではあるが)

100ゲット

>>86

いってることはもっともだが、プログラムの保守は他人がやるケースも多い。
「常人の短期記憶の容量」といっても難しいんだよね。

常識外れのアホプログラマーがガンガン問い合わせのメール送ってくることも
あるから、それを避ける意味でもグローバル変数は避けるのがよい。

自分を守るためにも。

>>90
yes
#どうもC++屋が多いな。ｽﾚﾀｲの言語はｃなのに。

今時珍しいストイックな人だな。

>>101
賛成。グローバル変数は使用禁止。
ただ「禁止」って言ってもグローバル変数に泣かされた経験のない人間には
少し細かく説明した方が良いと思ったから書いただけです。

>>89,>>94
>>93が代弁してくれてるが、誰もそんなこと言ってないよ。
命名、カプセル化と、発言の経緯をみてごらん。

で、いちいち反論するのもつかれてきたのであとご自由に。
...とか書くとえらい攻撃されそーで恐いが(笑

グローバル変数を禁止させたかと思ったら、巨大な構造体(グローバル変数っぽい
メンバが詰まってる)を全ての関数の引数に付けられたりして…

まあ、おまいらがそうでも良いアプリケーションを書いている
裏側では膨大なグローバル変数が使われている訳だが。

裏側のソースなんて読まないし、自分には責任ないんでＯＫ！

>>106
たまにそういう超弩級馬鹿がいるな・・・。

>>106
実際、それに近いコードに出会ったことある。
しかも関数(の作者)ごとに微妙に引数名が違ってて検索するのにも一苦労だったなぁ。

あと、引数の数がむちゃくちゃ多くて、それらを全部、ほとんどの関数で持ち回りしてるとか…

しかもポインタで渡してて、内容書き換わって返って来るから最低。
全部の関数がvoidになってたときには爆発した。

>>110
引数名が一致していることなぞ期待するのが誤りだ
そんなときは型名で検索するのが普通なのではないか

ここにもコードレビューを実施すべき理由が

>>113
それじゃぁ、関数定義の先頭しか引っかからないし。

スレッド処理はむしろグローバル変数の方が扱いと思うけどね。
静的領域にあるのに下手に隠蔽されているとどつぼにはまる。
他人が書いたコードの保守ならなおさら。

>>116
扱いやすいのか扱いにくいのかきちんと書いてくれ。

>>34
ラベルつきcontinue
ラベルつきbreak

try-catch 内で　多重ループ内でthrow new なんたらException();

なんたらException()でcatch

>>65
> >>60
> グローバル変数使用禁止の理由教えて。俺は命名こそが大事だと思うんだが。
> クラスだって巨大化すれば、メンバ変数もグローバルみたいなもんだよ(笑
藻前は「分割・統治せよ!!!!!!!!!!！！！！！！！！！！！！！！！」の原則に逆らうつもりか！！！！

>>96
もまえはgoto肯定原理者で人を不快にさせる病原菌をもっている。
ウザイから我らにうつすな。

>>106
> グローバル変数を禁止させたかと思ったら、巨大な構造体(グローバル変数っぽい
> メンバが詰まってる)を全ての関数の引数に付けられたりして…


そいつは
直径が100万光年ある超巨大原子のようだ(藁
知ってるか？　こんな原子が宇宙のどこかにあるんだってよ(ﾜﾗ

原子がオブジェクトで
原子核が電子によって隠蔽されたフィールド(C++でいういところのメンバ変数(ﾌﾟ　死語))で
電子がメソッド(C++でいういところのメンバ変数(ﾌﾟ　死語))だな（藁

喪前ら落ち着け、この中で会社に飼われているゴミＰＧ以外は
居るのか？飼われているゴミに反応して如何するの？
サラリーマンＰＧの様なゴミに惑わされるな。

もしこの世に自分の金玉と同じサイズの超巨大原子があったら？

それは近くにDQN-COBOLerが潜んでいる危険性があるということだ〜

基本的にサラリーマンの様な家畜が意見を述べる事自体が
間違いなのだが！飛べない豚は氏ね！！！

恐ろしいのはカプセル化されていない超巨大原子だ。

超巨大なプラスイオンが超強力な電場を作り感電する！
金玉の直径が１ｃｍだとして、その中に入る陽子中性子電子の数はいくつだっ！？
陽子の数、電子の数だけクーロン力が増える！
何エレクトロンボルトだ！？

恐ろしいクーロン力だ！その超巨大原子がコンピュータを破壊する！
超巨大原子(COBOLer)が超強力なクーロン力、超極力な電圧、すなわち静電気で
オープン系システムを破壊する。
恐るべきCOBOLerの大量のpublicなフィールド(プラスイオン)は人間に害を与える！
恐怖の開放電磁フィールド(公開メンバ変数)だっ！
このプラスイオンを撒き散らす恐怖の電磁フィールドは
トルマリンゴ(マイナスイオン新参者)でも防ぎきれない！

さらに恐るべきはアイソトープ(ポインタ操作)だ！
使い方を少しでも誤れば全員放射能で金玉原子にブッ殺されてあの世(デスマーチ)に！

本当の事を言って置くが
C++の様なゴミしか知らない屑は可哀想だなｗｗｗ

超巨大原子(無計画なプロジェクト)は崩壊し、
最終的に鉛(寂れたシステムまたは破綻したプロジェクト)に変わった・・・・。
超巨大原子が引き起こした悲劇は終わった・・・・・・。
これからもこのような悲劇は起さないで欲しい。

お前らよ、無理をするな、超巨大原子など作る必要は無いのだよ。
妙な元素(オペレータ定義、新言語作成など)を自作することばかり考える必要はないのだよ。
ランタノイドやアクチノイド(無謀なクラス設計の例)のように無駄にひとつの原子(クラス)内に
たくさんの電子(メソッド)や陽子中性子(フィールド)を
大量に詰め込む(定義する)必要など無いのだよ。
(動作が)不安定になって原子崩壊(スパゲティコード化)する原因を作るだけなのだよ。

人類、そしてこのよに存在する全ての生命体(すなわち、Java, Smalltalk)はつまらない原子に頼らず
炭素、酸素、水素、窒素といった限られた少ない部品(クラス)の組み合わせだけで分子(デザインパターン)、
ポリマー(Iteratorパターン)、有機化合物(フレームワーク)、
高分子化合物(アークテクチャーパターン)、細胞核・ミトコンドリア・etc(コンポーネント)、細胞(パッケージ)、
生命(人工知能)などを作り上げることができるのだ。

例えば酸素クラスと水素クラスという組み合わせでシンプルで人間、生命にとってかけがえの無い
すばらしき美しい水分子クラスができたのだ。なのにおまいらはプルトニウムとかしか作らない！！

フレームワーク(有機化合物)を作らずしてグローバル変数とポインタ演算だらけのコード(プルトニウム)を
作るだと！？　それは許されん！！！！

システム障害・サーバダウン・デスマーチ(ビキニ環礁水爆実験、チェルノブイリ原発事故)を起させてたまるものか！

植物はなあ、もっとも効率よくエネルギーを代謝しているのだぞ。
それにくらべ自動車、発電所や工場はなんとエネルギーの無駄遣いをしていることか。
おれたちは発電所がなかったらプログラマとしてやっていけないが、いつか生命体からエネルギーを
大量に確保する技術の恩恵を受けるべきだ。人類と地球の将来のために。

おやくそく
・長文ネタやる時はテーマを思いっきり絞るか、短いセンテンスを重ねるか、読んで楽しめるように工夫しましょう。

>>127
逝って良し

・・・つくづく勝者のいねえプロジェクトだよナ・・・
誰がいつgoto使ってもいい・・・すべては自由・・・
約束事なんか何もねえ

・・・そして巨大な構造体を引数にするのも自由だ
永遠に保守性なんか上がらねえ

ハマるヤツとキレるヤツ・・・　それだけだ
・・・クソ判断だったな　コボラー課長よ・・・

>>130
お気の毒に。
＞・・・クソ判断だったな　コボラー課長よ・・・
これが元凶だったようですね。言語設計思想からして全然違うのに。
「なんかで成功するとその方法が常に通用すると思いこんでしまう」という技術者失格な奴が多いんだね。
#この傾向はコボラー達に色濃いと思うのは俺の偏見か。

>>120
いえ、それは病原菌の性ではなく、gotoアトピー患者が過敏なだけです。

>>132　うん
アレルギー体質の治療ってアレルゲンを遠ざけることではなくて、
アレルゲンに対する過敏性を解消することなんだよね。
アレルギー体質患者のためにもgotoを見せてやらなければ。

>>131
コボーラに限らず、学生〜新人の期間に特定の環境しか習得しなかったやつは大抵そんな感じだ。

それで134は使えない新人と言われるわけだ。
明日からコンビニ行けよ

ｃ言語研修でgotoを使わせてみなかったのは失敗だった。
goto使えない奴はいつまでたっても使えないのかも。

NIFTYのプログラマーフォーラムでうざい長文を書くヤシが
何人かいるな。かえれ！

だからgotoなんて使うとタイプライブラリがＮＵＬＬで
スタックがヒープにくい込むわけでＤＣＯＭが
フーリエ変換なわけよ。わからねーだろーなー。

ps. おっと忘れてた、新聞配達行かなきゃ

おまいらgotoくらいでびびってんじゃねーよ
金玉ついてんのか〜

>>139
びびっている奴は、びびっていることを決して白状しない
「見るのが不快」「怖い」という負の感情を隠すために
「構造化がルールだから」とかいう理屈をこねたり、
「PGやめろ」とかいう怒りの感情を表明するのが典型的な反応だ。
まあ「gotoを全面否定する論理的な根拠」ってのは存在しないから、
このような反応をするのも仕方ないが。

>>139
女子プログラマーもいるぞ（w

「gotoが使えないならsetjump(),longjump()を使えばいいじゃない」by マリー

今どきなら「throwを使えばいいじゃない」のほうがより適切と思う

先生！ループの前から深いループ中に飛び込むのにsetjump(), longjump()は使えません！

#define setjump() LABEL:
#define longjump() goto LABEL
じゃだめ？（w

>>144
それってgoto使ってもstack吹っ飛ぶんじゃないの？

>>146
まずは、吐き出されたアセンブラを見たら？

>>140
いや、びびってるよ。
整備されたソースコードがボロボロになっていくなんて考えただけでも怖い。
gotoを見るのは確かに不快だ。
構造化は混沌に秩序をもたらすルールだよな？

パフォーマンス追求以外の理由でgotoを使うやつは馬鹿だ。
プログラミングが下手だという理由で馬鹿呼ばわりされるのではない、
馬鹿げた事を正当化しようとするから馬鹿呼ばわりされるのだ。

>>144
ループの中に飛び込むなら switch 〜 case 使わないとね。

>>148
＞構造化は混沌に秩序をもたらすルール
確かにそうだ。
しかし「秩序をもたらす」のは「構造化プログラム設計」であって「構造化コード」ではない。
gotoはコードに属する問題であり、プログラム設計に属する問題ではないんだ。
これを無視して一概に「構造化」を語るのは誤りだ。

あほですか？
「構造化されたコード」を書くことによって「構造化されたプログラム設計」が実現されるんだろうが。
コードレベルですでに構造化が壊れてるようなものしか書けない奴に、設計なんて語る資格なし。

>>151
つまりあなたはは抽象的思考ができないということですね。

goto hell;

hell:
goto heaven;

>>150
構造化フロー制御の話だろ？
わからないくせに出てくるな馬鹿

>>151=155
わかったからもう出てくるなあほが

なかなか素敵だ(´,_ゝ｀)ﾌﾟｯ

結論：
前方参照ジャンプが出来ないので、setjump(), longjump()はgotoの代わりにはならない。

>>151
ボトムアップのみの一方的な視点だな。
ボトムアップは場合によっては有効だが、トップダウンの方が有効な場合の方が多いだろう。
#これは業務アプリが最大の分野であるがためだが
＞「構造化されたコード」を書くことによって「構造化されたプログラム設計」が実現されるんだろうが。
「構造化プログラム設計」って言葉の意味を知っているのか？コードとは無関係だぞ
関数間の参照／被参照の依存関係＆個々の関数の強度と結合度のことだ

構造化の点からいくとbreakやcontinueも使わない方が良い

>>160
当然、「最終行以外のreturnも」だよね。
goto禁止論者に聞きたいんだけど、この三種の文、
「break（多分caseラベルbreak除く）」「continue」「最終行以外のreturn」
のそれぞれの使用可／不可を答えて欲しいな。

>>161
全部アリコに決まってんだろ

最終行以外のreturnは何で駄目？

>>163
構造化の妨げになるため

>>164
どうして構造化の妨げになるの？

>>165
164では無いが。
・連接反復選択の三種の制御構造のみを使用する
・入口と出口は一つずつ
の条件で、全ての論理が記述可能だ。
という構造化定理（ストラクチャード定理）というものが大昔に証明された。
これに準拠して記述するのを「構造化プログラミング」という。
＃本当は構造化原理主義
出口が複数あるのは純粋な意味での構造化プログラミングでは無いからだ。

なるほど
ハマスと同類ですね
くだらないルールに拘る奴等は

gotoを使うのはかまわんが、用も無いのに使う奴は馬鹿。

用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿
用も無いのに使う奴は馬鹿

おまえって。。。

なんか分岐して出口一つにすると行数が多くなって嫌とか言って
そこら中にreturnばらまいてるコード結構あるね。
そういうコードは保守するとき、苦労するんだべさ。

フラグ使うのもダメってよくいうけど
使わないサンプル書いてくれ

＞break（多分caseラベルbreak除く）
＞continue
この二つはまったく考え無しに使う。
条件チェックを複雑にしないためのシンタックスシュガーだから
構造化を崩しているとは思っていない。

＞最終行以外のreturn
滅多に使わない。大抵の場合は戻り値を一時変数に格納するだけで
最終行のreturnで問題ない。
(このスタイルは一時期VBを使わなければいけなかった時に身についたもので苦肉の策だったんだが、
結果的にとてもよいスタイルが身についたと思っている。デバッグ出力や一時的な変更などがすごく楽だ)
ただ抜けるために複雑な条件にしないといけない場合は使うが。

どちらにしてもわかりきった範囲にしか飛ばないのだから自由自在のgotoとは別物だと考える。

>>172
>＞最終行以外のreturn
>滅多に使わない。大抵の場合は戻り値を一時変数に格納するだけで
>最終行のreturnで問題ない。

こうしたいがためにコードを複雑にしているアフォがなんと多いことか。

>>166
そして、その「論理的には」可能な「完全な構造化」を
現実に実装できると思い込んでいる脳足りんが
goto を使うな、と言っている。

処理の流れを有向グラフにしたら
「完全な構造化」が如何に無駄なものか
判りそうなものなのにな。

＞条件チェックを複雑にしないためのシンタックスシュガーだから
gotoもループ脱出や例外処理のシンタックスシュガーですｗ

>>174
連中は、まず「gotoは『絶対』使ってはダメ」という原則がアプリオリにあって、
それに、構造化だの保守性だの適当な理由をつけてるだけだから、一貫性が
内容に見えてもそれを指摘するのは全くの無駄だよ。

try-catchでgoto文の代わりができるいらねえだろgotoなんて

邪魔邪魔

goto文はアージャイル開発の敵！

C++の話をもちだす>>177はｱﾌｫ

// 悪い関数の例 (9行)
int func(int arg) {
　int result;
　if (arg > 0 && arg < 100) {
　　result = 1;
　} else {
　　result = 2;
　}
　return result;
}
// 良い関数の例 (7行)
int func(int arg) {
　if (arg > 0 && arg < 100) {
　　return 1;
　} else {
　　return 2;
　}
}

>>176
うん、まあそうなんだけどね。でもそういう正論を言ったら話が終わってしまう。
「goto禁止論者をからかう」という背景で話をすることによって、
「goto誤用の撲滅に一歩でも近づけたらいいな」という個人的な楽しみが失われるな。

ようはこういうことだ、
まともなプログラムが組めない輩が安易に
GOTO文を使うなってことだ。逆にロジックを
ちゃんと組める熟練した人間なら必要に応じ
てバシバシつかってもいんじゃないかな。

>>179
問題です。
その func の戻り値をデバッグの為に printf で出力したいと思いました。
func はあちこちで使われています。
変更が少なくてすむのはどっち？

また初期コストと変更のコストで削減した時に効果が高いのはどっち？

>>179
// 良い関数の例 (1行)
int func(int arg) {　return (arg > 0 && arg < 100)?1:2; }
じゃダメか？

>>181
＞逆にロジックをちゃんと組める熟練した人間
あ！本物のプログラマ発見！！

>>182
意味不明だなあ。「funcの戻り値を出力」って、普通funcの参照元でやるよ。
func内部で出力するの？。

あのさあ開発コストを負担する組織と保守コストを負担する組織が必ずしも同一でない
って事は認めるよね。
そのような現状で「開発コストと保守コストの総和の最小化」なんて言っても
開発しかしない組織は聞く耳なんか持たないんだよ。
開発しかしない組織は開発コストにしか興味が無いんだってば。

＞開発しかしない組織は聞く耳なんか持たないんだよ。
すげー優秀ですね。普通は開発ってトライ＆エラーの連続だと思うんですけど
開発って変更の連続ですよね。ビルド通ったらバグもエラーもなく動かしちゃう人達ってほんと尊敬します。

>>185
＞意味不明だなあ。「funcの戻り値を出力」って、普通funcの参照元でやるよ。
＞func内部で出力するの？。

DBC的には内部でチェックのが正しげ

>>182
デバッガ使え。

>>188
ヲチポを増やすと重くなります。
一時変数resultに格納するとヲチポは一つで済みます。

まあデバッガで検証できるレベルのバグは大したことはない。
問題はタイミングによって挙動が変わるような処理だ。
そういう場面でもっともお手軽でかつ確実な方法がprintfによる出力。

>>186
テスティングフレームワークを使ってテストケースが書いてあれば、
戻り値チェックだけで（ｒｙ

>>190
デバッガのマニュアルを読んでみよう。
ブレークポイント以外にもいろいろ使い方あるよ。

天才や本物のプログラマはgotoも最終行以外のreturnも恐れずに使う。
一般プログラマのように常に勉強をし続け、良いスタイルを身につけ続けていかないと
ちゃんとプログラミングができない者たちは天才や本物のプログラマの真似をしてはいけない。

>>190
printfを入れるだけで出なくなることもあるけどな。

組み込み、制御系では実機とデバッグ環境に違いがあって
製品組み込み後の総合テスト的なデバッグではデバッガはまずつかえんね。

それは組込系に限った話ではないのでは？

>>171　フラグ使っているサンプルを書いてみ。使っていないサンプルに直してやるから。

>>182
int func(int arg)
#ifdef DEBUG
{
　　int _func(int);
　　int result = _func(arg);
　　printf("%d\n", result);
　　return result;
}
static int _func(int arg)
#endif
{
　　// 本当のfuncの処理

>>198
そーれーはーさーすーがーにーあーぶーなーいー
と思われ。
そういうプリプロセッサの使い方をいつもしているの？

>>199はネタだろ？

天才や本物のプログラマはgotoも最終行以外のreturnも恐れずに使う。
一般プログラマのように常に勉強をし続け、良いスタイルを身につけ続けていかないと
ちゃんとプログラミングができない者たちは天才や本物のプログラマの真似をしてはいけない。

現場で必要とされるのは、そんな「天才」だの「本物」じゃないだろ。
誰が読んでも分かり易い、メンテナンスや拡張がし易いコードの書ける
プログラマだろう。

ﾈﾀﾆﾏｼﾞﾚｽ?

>>199
解説よろしく

東大出身のPGが書いた大量のフラグを使ったプログラムを見て
フラグを間違えずに使える奴こそ、「天才」だと思った。

膨大な規約をスキなく覚えかつ実践できる奴もね。

>>202
俺は
「誰が読んでも分かり易い、メンテナンスや拡張がし易いコードの書けるプログラマ」
が本物だと思うが。

そんなものが存在すると思ってるうちは自己満足なコードしか書けない。

>>204
解説って・・・>>198は、
DEBUGが定義されているときはfuncは_funcを参照してその返り値を出力し、
DEBUGが定義されていないときはるときはfuncは「本当のfuncの処理」を行う。
つまりDEBUGの定義／非定義によって全然違うプログラムになってしまう。
このような使用方法は非常に危険だから「危ない」って言っただけだが。

＞全然違うプログラムになってしまう。
ネタ？

日本人って「手段を目的と取り違える倒錯」に陥りやすいよね。
社会科学系の学者には先の敗戦の主因もそこにある、という人もいる。

この話題は実はすごくシンプルなことなんじゃないだろうか？
「gotoを使わない」のは、主にコードの可読性を上げる、という目的の手段のはず。
だからコードの可読性が重要なプロジェクトで、かつコードの可読性を悪くすると
思われるケースではgotoを使うべきではない。

逆に、コードの可読性に資するのではれば（そんなケースが実際にあるかどうかは
別として）躊躇なく使えばいいし、あるいはコードの可読性以上に重要な目的があって
その目的にかなうなら、使うのは仕方がない。

で、実際そのようなケースがあるのかどうかだが、私はほとんどないと思う。
強いて言えばVBでCのcontinueの代用として使うケースと、ワンチップマイコン
みたいにスタック領域が大きくとれないシステムで「あるルーチンＡをコールして
リターン」の代わりに直接そのルーチンＡに飛ばすときぐらいか。

話は変わりますが、私は関数内ルーチン（gosub）は、場合によっては
非常に有用だと思うんですが皆さん的にはどうでしょう。

文句があるならカーニハンとリッチに言いなさい。

>>211
いいたいことは判るが、「可読性」を定量的に量れないと無意味。
gotoを使ったコードのほうが可読性が高いと思う奴もいるので。

>>209
デコレータパターン

>>211
とりあえず、このスレと前スレを読み返してみたら？

>>213
goto否定原理主義者的には、「gotoを使ったほうが読みやすくなるようなコードを
書くほうが悪い。」だそうですが。

手段を目的と取り違える倒錯

gotoを使ったコードは常に可読性が劣る
↓
なぜならgotoを使ったほうが可読性が良くなる場面など存在しないからだ
↓
もし存在しているように見えるなら、それは書き方が悪い
↓
その場合、gotoを使用しないもっと良い書き方が常に存在する
↓
なぜその書き方がよいかというと、gotoを使わないほうが可読性が良いからだ

>218
気持ちはわからんでもないが、
小学生並の主観のみの意見は説得力ないわな
もうちょっとがんばれ

>>219　>218は「goto否定論者への単なる煽り」にしかみえないんだが。

gotoを使わないコードって可読性良い?
俺の見た範囲ではむしろフラグとか使いまくりでダメダメだったよーな気がします。

>>218は、「可読性」を「保守性」に変えて読んでもいいな。

goto 使いたくなる例;

┌──┤
│　 ＜X?＞─┐
│　　　│　　　│
│　　[　A　]　 │
│　　　│　　　│
│　 ＜Y?＞─┤
│　　　│　　　│
│　　[　B　]　 │
│　　　│　　　│
│　 ＜Z?＞─┤
│　　　│　　　│
│　　[　C　]　 │
└──┘　　　│
　　　　 ┌──┘

いや、これは C なら break 使えば済むな…
まぁ構造化理論でいくと goto と break は等価だから、と言い訳しておこう。

>>223
for(;;){
if(! X ?) break;
[A]
if(! Y ?) break;
[B]
if(! Z ?) break;
[c]
}

...goto使うまでもないが?

...かぶりますたね

breack文やcontinue文が用途を限定したgoto文として考案されたものである
って事を知らない人もいるのだね。

>227
照れるなよ。
自分のことだろ？

breakやcontinueは、もともと問題が少ないgotoの使い方だから、
シンタックスシュガー化されたわけだね。
C++の例外も同様(gotoの機能に限って言えば)。
あと、label付きcontinueやbreakができる言語もあるな…

breackってのはジュースかなにかですか?

地方限定か？

do{
if(! X) break;
[A]

if(! Y) break;
[B]

if(! Z) break;
[C]
}while(0);


...って書くくらいならさ、
if(! X) goto next_block;
[A]

if(! Y) goto next_block;
[B]

if(! Z) goto next_block;
[C]

next_block:
でいーじゃん?

前スレにそれに関する論争があったな…

「gotoを使うと常に可読性が悪くなる」という根拠の無い信念
を持つ人間がいなくならない限りgoto論争は終わらないな。

言語研修のときに「gotoは使うな」って言われて、
仕事内容が「比較的ロジックが単純であるカテゴリの業務アプリ」だったりすると、
gotoなぞ使わなくとも済むからね。
上記のような根拠の無い信念が形成されるというわけだ。
その種の人間は年々沢山、増えるから「goto論争は終わらない」というしかけ。

goto肯定派は大阪人の交通マナーは素晴らしいと思うの？

赤でも危なくないから渡るんじゃい！って、
危なくないと思ってるのは自分だけ。
こういう人達が蔓延っている中から
いつも酒飲みながら運転するトラックのドライバーとかが出てきて
罪もない幼子の命を奪ったりするんだよ？

>>234
ロジックが複雑だと感じたときは
考え直せ
たいてい　簡単なロジックの組み合わせに直せる。

>>235
せいぜい80Km/hで高速を走らない一般ドライバー程度のことだyo


>>236
gotoの方が簡単だろ?

>>235　500m先まで見えてて、車が全く見えなくても100m先の横断歩道まで歩くタイプ？

横断歩道は車のためにある。
歩行者のためにあるわけではない。

>>235
そういうの、我田引水って言うんだよっ

>>237
複雑なロジックの時点で簡単ではない

それで妙なネストや意味の無い関数分けが増えるのか…

おい旧世代のイキモノ
とっとと進化するか滅べ

>>237
それが割れ窓。

>>238
もう>>239が説明してくれてるけど、運転者の話をしている。
運転者は責任があるから、この比喩に相応しいが、歩行者は一般的に責任が非常に軽いので
相応しくない。

>>240
つまりお前は負けを認めたわけだな？
反論できないんだろ？

gotoを使う奴は人殺しのトラックドライバーと同じ。

反論あるやつはちゃんと反論してみろよ。

> gotoを使う奴は人殺しのトラックドライバーと同じ。
全く違う。同じ部分なんて一つも無い。

反論してみました。

>>245
gotoを誤用するとスパゲティになるのは認めるな？
交通ルールが世の中から無くなったら交通事故が多発して死亡者が後をたたないのは認めるな？

構造化フロー制御でgotoの誤用が防げるのは認めるな？(認めないなら構造化フロー制御の構文をもう使うな)
交通ルールで交通事故が防げるのは認めるな？ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな？

構造化フロー制御はプログラミングの世界の交通ルールだ。
たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
それを守らないと必ず大きな事故をひきおこす(これを割れ窓のセオリーと呼ぶ。)

さあ、矛盾の指摘なり、反論なりまともにしてみろ。

一応ツッコんどくが・・・例えが悪いよ。

深夜
人も車もいない道路
目的地は目の前
道路を横断すれば数秒
歩道橋を渡れば5分

それでもあなたは歩道橋を渡りますか？

>>248
>239

goto使うったって
数万、数十万ステップ、それ以上に1箇所あるかないかだろ。
なんの問題があるんだ？
それよりもgotoを使わないことを意識した糞コードが
山のようにあるほうが実際迷惑だな。

>>246
245ではないが。力の入ったレスに敬意を感じたのでレスさせてくれ。
＞gotoを誤用するとスパゲティになるのは認めるな？
＞交通ルールが世の中から無くなったら交通事故が多発して死亡者が後をたたないのは認めるな？
＞構造化フロー制御でgotoの誤用が防げるのは認めるな？
全部認める

＞交通ルールで交通事故が防げるのは認めるな？
認めない。
交通ルールなんて国によって内容とその量に格段の開きがあるぞ。
交通ルールに違反する気なぞ全く無くとも、前方不注意で起こる事故だってある。
＞ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな？
知らないよ。

＞構造化フロー制御はプログラミングの世界の交通ルールだ。
規約になっていなければ、絶対に認めない。そんなことを勝手に決められてたまるか。
このあたりが焦点だろう。

＞たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
＞それを守らないと必ず大きな事故をひきおこす(これを割れ窓のセオリーと呼ぶ。)
割れ窓理論って
たった１枚の割れ窓の放置から起きる荒廃の始まりで、街は荒れ、無秩序状態となって犯罪は多発し、地域共同体を作っていた住民は街から逃げ出し、街が崩壊する
ってやつだな。
「gotoは割れ窓である」ということ自体を認めない。

以下は俺の意見
「大きな事故を引き起こす」ってのは「gotoの誤用」が原因の一つになりうることを認める。
しかし「gotoの誤用」は「大きな事故を引き起こす」原因群の最大の悪玉ではない。
また「gotoの誤用」を起こさないための仕組みとして「goto使用禁止」を選択するのは不適切だろう。
#大きな事故を引き起こさない事がそんなに重要ならば、
#goto使用禁止を叫ぶより、もっと有効な行動があるのではないか

>gotoを使わないことを意識した糞コード

早い話おまえみたいなクソ低レベルな奴がいなければ何の問題も無い

なんかとてつもなく頭が悪い人が何人かいるような......。
なんでこんな思考力ない人たちがＰＧなんかしてるんだろ？

>>246
こういう人のことを「土人」っていうんだろうね。
「手段」の妥当性は目的に対する合理性で評価されるべきです。
目的を忘れて手段に固執するのはフェティシズムです。変態さんです。
「村の掟」で自縄自縛する前近代人です。

一般に「gotoを忌避すべし」とされるのは、gotoの乱用は一般に
コードの可読性を下げるからです。「それがルールだから」ではありません。
「ルールだから守る」があなたにとって説得的であるとすれば、
それはあなたが近代社会の住人ではないからです。

>構造化フロー制御はプログラミングの世界の交通ルールだ。
>たしかに誰もいない赤信号を待つのは馬鹿らしいかもしれないが、
考え方が倒錯しています。交通ルールの目的（の１つ）は交通事故を
避けることです。だから交通事故の抑止に対する合理性がないルールが
仮にあるとすれば、そんなルールは破棄されるべきです。
「悪法も法」なんていうのは近代を理解せぬ愚か者のセリフです。

同様にgotoを使うことが目的（コードの可読性の確保）に合致するなら、
gotoを使わない理由はありません。繰り返しますが、目的を忘れて
手段に固執するのはバカげています。

＞....(これを割れ窓のセオリーと呼ぶ。)
呼びません。全然違うよ。恥を上塗りしないうちにググルがよろし。

goto使う奴 -> 野蛮なテロリスト
goto使わなくても普通にコード書ける奴 -> 文明人

>>250
支持。
gotoなどより糞コードの方が保守性低下に直結する悪玉だ

>>253
各論を支持する。
が、「頭が悪い」とか「思考力ない」とか「愚か者」とか「恥を上塗」とかは書くな。

>>244
＞つまりお前は負けを認めたわけだな？
意味わかってない人ﾊｹｰﾝ( ・∀・ )
自分の書いたレスのどこが悪いのか良く考えてみようね(5点)

宗教だよ。
goto使いたい奴は使えばいい。

俺は使いたくないし、絶対に使わなければならないような状況になったことは無い。
使った方が良い場合というのにもほとんどお目にかからない。ゼロに近い。

俺の知ってる奴の中でgoto使う奴は、考え無しにいきなりコーディングする奴が多い。
確かに動けばまぁ良いけどよ。

「イヌの旨さは日本人には分からないニダ」って所か？

>>235もそうだけど、goto使用禁止原理主義者って結局↓の>>176の通りなんだよね。
議論にすらならないというか。>>218でそれが皮肉られたのが分からなかったのかなぁ？

176 名前：仕様書無しさん[sage] 投稿日：03/12/07 15:42
>>174
連中は、まず「gotoは『絶対』使ってはダメ」という原則がアプリオリにあって、
それに、構造化だの保守性だの適当な理由をつけてるだけだから、一貫性が
内容に見えてもそれを指摘するのは全くの無駄だよ。
~~~~
↑
無い様
だね(補足)。

gotoこそプログラミングの本質である。
ジャンプのないプログラミングなんてクリープのない(略

隠し味だね！

少し意味合いは違うかも知れないけど、
GUIのイベントループやシグナルハンドリングも本質的にはgotoなんだよね。
#元に戻ってくるからbasicのgosubみたいなものか

>>262
そうだね。でも関数参照自体もgotoだね。
「GUIのイベントループやシグナルハンドリング」は非同期だっていうおまけがついてるけど。

GoToも使いこなせん香具師はPGヤメレ！

goto使う使わないでどうにかなる奴は率直にいって能力が低い。
こんな糞スレにたむろって1000以上の糞レスつけてる奴は人生の愉しみ方を知らない。

>>248
goto使用者が運転免許証も持っていない事＝世論の流れを知らない事はわかった。

>>250
＞それよりもgotoを使わないことを意識した糞コード
これも先に突っ込まれたが、一つだけいいことを教えてやる。
gotoを使わないで初心者時代を過ごした人間は、無意識にgotoを使うことは無い。
あんたにとって「これgotoを使わないでどうやって書こう」が不自然なように
我々にとって「これgotoを使ってどう書こう？」や「このコードは何故gotoを使っているんだろう」は
極めて不自然だ。
そしてこの事実はこのスレで何度も出ている嘘をも暴く。
goto肯定派のほとんどが
「初心者時代はgotoを使わず、わかるようになってからgotoを使う」などというルートは踏んでいない。

>>251
＞＞交通ルールで交通事故が防げるのは認めるな？
＞認めない。
たとえば一時停止がルール化されていなかったら、
あなたが今まで成長するまでに車にひき殺されてるかも、と思いませんか？

＞交通ルールなんて国によって内容とその量に格段の開きがあるぞ。
いや、全部防げるとか完璧だとかは言っていないです。
交通ルールが事故を減らせるでしょう？と言っているのです。

＞交通ルールに違反する気なぞ全く無くとも、前方不注意で起こる事故だってある。
直進中に前方を注意していないのは既にルール違反だと思いますが。

＞＞ほとんどの交通事故が交通ルールを無視した為に起こっている事も認めるな？
＞知らないよ。
ちょっと書き方に一貫性がなかった。悪かった。
ここだけ歩行者や軽車両側にも交通ルールを守る義務がある事を前提とさせてくれ。
少なくとも日本の交通ルールは全員が厳守すれば車両の故障、土砂崩れなどの天災的なもの、
アクセルとブレーキの踏み間違いなどのどうしようもないレベルを除いて
ほとんどの事故はなくなる。これは事実だ。

＞＞構造化フロー制御はプログラミングの世界の交通ルールだ。
＞規約になっていなければ、絶対に認めない。そんなことを勝手に決められてたまるか。
＞このあたりが焦点だろう。
構造化構文をすべて捨てるか？
約束事に則って物事を行う事の大事さを知っている人間が、なぜgoto利用に拘るのか理解できない。

＞「gotoは割れ窓である」ということ自体を認めない。
簡単に乱用できて、乱用が破滅的事態を引き起こす物だという事はわかっていますか？
初心者/能力の低い人が逃げの手段に使う事がままある機能だという事はわかっていますか？
本当に意味のある使い方ならbreakのように誰か偉い先生がとっくに言語機能に組み込んでいるはずだと思いませんか？

>>253
＞一般に「gotoを忌避すべし」とされるのは、gotoの乱用は一般に
＞コードの可読性を下げるからです。「それがルールだから」ではありません。
gotoの乱用が一般的にコードの可読性を下げるので、構造化というルールができました。
これは卵が先か、鶏が先かではありません。あきらかにgotoの乱用が先です。
(もともとはgoto...jump/branch命令しかなかったのですから当然です。)

＞だから交通事故の抑止に対する合理性がないルールが
＞仮にあるとすれば、そんなルールは破棄されるべきです。
つまり赤信号でも人がいなければ通行してよいとルールを改定すべきだと
言っているんですよね？
goto肯定派も明文化できるまともなgotoの利用法があるなら提唱すべきでは？
(breakやcontinueは少なくともそうでしょう。)
偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね？

＞＞....(これを割れ窓のセオリーと呼ぶ。)
＞呼びません。全然違うよ。恥を上塗りしないうちにググルがよろし。
はぁ？どこがどう違うの？>>251のような反論なら
こちらにも反論の余地があるけど、あんたみたいに「どこが違うのか」すら指摘できないのは
問題外なんだけど。

構造化はルールでは有りません。終わり。

235は人生の愉しみ方を知らない。

>>235は、日本のドライバーのほとんどが日常的に交通ルールを破っていることを
どう思っているんだろう？

>>262
おまえがJavaにポインタがあるかないか論争の仕掛け人だな。

>>271
みんなが破っているから破ってもいいんだと言いたいのか？
まさしく割れ窓の一枚目が割られる瞬間だぞ。

言っておくが発信前に車両の前後左右および下を確認するのはルールだ。
下に子供がもぐりこんで遊んでいるのを見逃して殺してしまって裁判所で
「誰も発信前に車の下なんか見てる人居ませんよ」って言っても
お前は人殺しだぞ。

ええと、スピード違反のことを言ってるんだけど。

交通板に池

>>267
＞構造化構文をすべて捨てるか？
＞約束事に則って物事を行う事の大事さを知っている人間が、なぜgoto利用に拘るのか理解できない。
「goto禁止が約束事である」ことを認めない。構造化構文は当然捨てないよ。なぜそう両極端に考える？
有用だと思う文は全て使うんだ。

＞簡単に乱用できて、乱用が破滅的事態を引き起こす物だという事はわかっていますか？
＞初心者/能力の低い人が逃げの手段に使う事がままある機能だという事はわかっていますか？
コードレビューをすることがgoto誤用の一番有効な防止策。
goto誤用のみならず他の「コードにおける破滅的事態を引き起こす物」にも有効だしね。
#わざわざ「誤用」を「乱用」に言いかえているのは「薬物乱用」という言葉のネガティブイメージを利用
#しようという無意識の戦略があったのかな？

＞本当に意味のある使い方ならbreakのように誰か偉い先生がとっくに言語機能に組み込んでいるはずだと
＞思いませんか？
breakは単なるgotoの機能限定版。
「本当に意味がある使い方が存在しない」のなら言語仕様にgotoは存在しないだろう。
言い換える。
ｃの言語仕様にgotoが存在するのは、言語設計者が「本当に意味がある使い方が存在する」と判断したからだ。

まぁ、gotoを使わないことは「ルール(それも法律と比較するような)」ではないわけだから、
その時点で>>235の論は成り立たないわな。もちろん、「gotoを使わないこと」をルールと
することを妨げているわけじゃないよ？

まぁ、敢えて>>235の比喩の下で言うなら、赤信号では必ず止まる事が「ルールでない」
世界で、「周りに誰もいないのに」必ず赤信号で止まれというのも、そりゃおかしいだろ
って事ですな。

>>235は、まず、構造化が交通ルールと比喩するに足る「ルール」であることを示してください。

>>256
失礼。

>>268
>偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね？
それは一言でいえば「不毛」だからじゃないでしょうか。
つまり(１)「『goto絶対に禁止』の弊害」を悟るのは、「gotoの乱用の弊害」を
悟るより遥かに易しい（ただし、普通の思考力があれば）し、(２)そもそもgotoが
有用な場面はあまりないから。

>はぁ？どこがどう違うの
だからググれと......。
「破れ窓理論」は、乱れた環境が犯罪に対する心理的な閾を下げる、
とする仮説。

一方、信号を守らないと事故に繋がるのは、不特定多数が「信号は概ね守られる」
という期待を前提に行動するから。環境は関係ない。

＞>偉い先生は何故だれもあなた方のいう「正しいgotoの利用法」を提唱しないんですかね？
＞それは一言でいえば「不毛」だからじゃないでしょうか。

というか、してるじゃん(新しい構文として)。
C以外は知らないのか？

＞有用だと思う文は全て使うんだ。
何度も繰り返しているが、その考え方が誰も居ない赤信号は通るべきだと主張する人間のやり方なんだよ。

＞コードレビューをすることがgoto誤用の一番有効な防止策。
あんたがコードレビューをする時に使うgotoの正しい使い方の説明と間違った使い方の説明をしてみてくれ。
曖昧なものじゃなくて、本当に有用なら歴史の穴として構文に組み込むべきだし、
曖昧な物だったりすればgotoの乱用を引き起こすはじめの割れた窓だ。

#わざわざ「誤用」を「乱用」に言いかえているのは「薬物乱用」という言葉のネガティブイメージを利用
#しようという無意識の戦略があったのかな？
無意識じゃない。本当は薬物中毒者の比喩を出そうかとすら思った。
(これ以上抽象論になると余計わかりづらくなりそうなのでやめておいた)
薬物中毒者が「いつでもやめられる」と言いながら薬に手を染めていく様は
まさしく割れ窓の一枚目を放置する人間と同じだな。

＞ｃの言語仕様にgotoが存在するのは、言語設計者が「本当に意味がある使い方が存在する」と判断したからだ。
だとしたら酷い判断ミスだな。
(Cの文法に判断ミスがないとは言わせない。関数ポインタの書式や配列の書式はカーニハン自らも反省しているようだし、
それ以外にもconstの位置などは随分とわかりづらいルールになっている。)
俺はCにおけるgotoはパフォーマンス上どうしてもgotoが使いたい時の為にあるのだと思う。
決してgotoを使ったほうが美しいとかわかりやすいとか、そういう理由で残してあるのではないだろう。
(あとトランスレータの目的語として使われたりする時も有効だと思うが、これは人間の仕事じゃない。)

>>251以外
今日は寝るので明日までに(少なくとも>>251くらいの)まともな反論を書いておけよ。

おぉ。上手い具合にボロボロにされてる。

喩えを使って非難するやつってさぁ。ほんと反論が簡単だよ。
喩えを否定すればもうボロボロ。喩えなんて所詮喩えなんで、
違うといえば当然違うからねぇ。

なんか235が一番まぬけに思えるのはもれだけ？

んじゃ、そろそろ、悪質な使い方をされうるswitchの禁止の話でもするか？
あぁ、変数名が任意につけられるってのも悪質なコードが量産されて
「割れ窓の一枚目」になってしまう可能性があるから、禁止したほうがいいな。

…って前同じ事書いたような気がするな…
あの時は、C言語自体使うべきでないって結論だっけｗｗｗ

藻前ら全員「プログラミング禁止」ってことで、結論は出たみたいだな。

>>281
そうそう。反論できないところには、本当に律儀に反論しないからね…
だから、我田引水だって言われてるのに…。

>>284
ついでに、悪質な言動や間違った言動をしてしまう自然言語も
「割れ窓の一枚目」を作らないためにも禁止したほうが良くないだろうか？

>>283
そういう話がジョークで済まないところが日本の悲しいところだと思う。
別にコーディングに限らなくても。

手段を目的化してそれに固執する困った人が、周りにどれだけ多いことか。。

自由人気取ってんのかオマエwww

固執しない、ということと、自由に(＝我侭に)振舞うということは違うね。
本当の自由は云々ってよく言われることでしょ？

さてさて、>>235は、無理な比喩とそれに基づく勝手な前提を取り除けば、
そんなに間違ったことは言っていないと思うので、まずそういう感じで出直して
もらえれば、かなり有意義な議論になるのではないかと思う。

とりあえず18才未満はgoto使用禁止という法律を作る所から始めては
どうか。

235から喩えとったら何もねーじゃねかよ

>>280
#だいぶ興奮しているね。悪口が書いてあっても感情的になったら駄目だよ。眠れるかな？

＞＞有用だと思う文は全て使うんだ。
＞何度も繰り返しているが、その考え方が誰も居ない赤信号は通るべきだと主張する人間のやり方なんだよ。
やり方って・・・。「誰も居ない赤信号は通るべきだと主張」なぞしていないぞ。
「私は、誰も居ない赤信号は通る」という主張だが。
私は290ではないが、>>290をレスしたい。正確には
×無理な比喩とそれに基づく勝手な前提
○勝手な前提とそれに基づく無理な比喩
と思うが。

＞あんたがコードレビューをする時に使うgotoの正しい使い方の説明と間違った使い方の説明をしてみてくれ。＞曖昧なものじゃなくて、本当に有用なら歴史の穴として構文に組み込むべきだし、
＞曖昧な物だったりすればgotoの乱用を引き起こすはじめの割れた窓だ。
誤用か誤用で無いかの判断は一筋縄ではいかないよ。個人毎／プロジェクト毎に判断は違うだろう。
「曖昧」とは違う。多種多様なんだ。
gotoについてのコーディング規約が「極力使用しない」という曖昧な表現が多いのはこれが原因だな。
つまり「XXXのときだけ使用可」って書きたくてもXXXの部分が決められないわけ。
私の判断を聞いてどうなるかが理解できないが。「正しい使い方」の方を書いてみる。
多重ネストからのネスト直後への脱出と有限状態遷移の表現だ。それ以外は全部誤用だ。曖昧かな？
#前者は、gotoでなくreturnを使うほうがベターである場合も多い。
#そのときはプログラム設計の修正もしてもらうけどね。前者はjavaのbreakにあるね。

＞だとしたら酷い判断ミスだな。Cの文法に判断ミスがないとは言わせない。
総論は認める。だがgotoについては認めない。
#構造化構文＋goto有りの言語はすべて判断ミスであるとの主張なの？

＞俺はCにおけるgotoはパフォーマンス上どうしてもgotoが使いたい時の為にあるのだと思う。
ふーん。私はそういうケースにぶつかったことは無い。最近のコンパイラは優秀だしなあ。
というかそんな時はインラインアセンブラの使用が常道と思っていたが。

＞決してgotoを使ったほうが美しいとかわかりやすいとか、そういう理由で残してあるのではないだろう。
うーん。何度も同じようなレスを書くのはいやだから白状する。
私は前スレの124だ。前スレの699と700がレスだ。
つまり、「gotoを使ったほうがわかりやすい場合がある」という主張だ。
少なくとも（私を含めて）複数の人間がそう表明している。
#あなたはもしかして前スレの828ですか。言っていることがとても似ている。

答えさせるばかりでなく、答えて欲しいな。>>161 への回答をお願いしたい。

朝なので急ぎ足。想定範囲のみ答える。残りは帰ってきてから。

>>293
そうくると思った。誤用かどうかは酷く曖昧なんだ。
聖書読めよ。人が人を裁く事の難しさを考えろ。
もちろんそれはgoto否定派も同じだが、goto否定派には
構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
人が生きるために法律というルールに寄り添わざるをえないように、
高級言語でのプログラミングでは構造化フロー制御から外れたら
生きている人間が生きている人間を裁かなければならないんだ。

多重ループから一気に抜けたいんですが、当然goto使いますよね

>>295
なんか、言ってることがむちゃくちゃなんだけど、大丈夫かなぁ？

へんしゅう-きょう -ｼﾌｷﾔｳ [0] 【偏執狂】
⇒モノマニア

モノマニア [3] ＿monomania＿
（１）一つのことに異常な執着をもち，常軌を逸した行動をする人。偏執狂(ﾍﾝｼﾕｳｷﾖｳ)。偏狂。
（２）一つのことにこること。また，その人。

>>296
「多重ループになるような設計が悪い」
「一気に抜けたくなるような設計が悪い」
否定原理主義的な模範解答です。問題のすり替え。

>>296
>>296
>>296
>>296
>>296
>>296
>>296
>>296

breakという原罪を背負ってコーディングしているのか。

>>296みたいに限定された使い方でもダメだとかいう奴は
たぶんbreakやcontinueやswitchも当然ダメだと言うんだろうなぁ
なんて効率の悪いやり方だ

>>300
「多重ループになるような設計が悪い」
「一気に抜けたくなるような設計が悪い」

↑あなたこれ理解できないの？

>>301
お前が理解してないことは理解してますよ？

＞構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
副作用のある変数の使い方もやめよう。偉い先生が唱えてますよ。
ルールです。反したら死刑。

>>295
>構造化フロー制御という偉い先生が唱えてくれて一般に知れ渡った方法論がある。
やっと判ったよ。
頭が悪くて自分で考えられないから
「なんか偉い人が言ってるから間違いない」と思い込む、
一種の宗教なわけか…そりゃ判り合える筈もないな。
そうか、構造化フロー制御か…

ところで君、オブジェクト指向に関して
どこかのｽﾚで同様の頓珍漢な会話してなかった？

>304
こやつはどこのスレでもそうだよ(´,_ゝ｀)ﾌﾟｯ
ばか丸出しでかわいいやつさ。
でも飽きてきたな。

>ところで君、オブジェクト指向に関して
>どこかのｽﾚで同様の頓珍漢な会話してなかった？
お前らはただ宗教論争がしたいだけちゃうんかと(ry

「勝手な前提とそれに基づく無理な比喩」
ところでｵﾏｲﾗ、↑の「勝手な前提」と「無理な比喩」ってなんだか分かってるかい？

>>301
ネタだよね？本気で言ってないよね？

「前方へ戻るgotoは、ちゃんとループを作る命令が整った言語が使える以上
あえて使う意味は無い」なら分かる。

「後方へ飛ぶgotoを使った方がシンプルにかつ分かりやすく記述できる場合
(特に深いループから一気に抜ける等)」
も禁止にしなければならない理由が分からない。

街中を素っ裸で歩いたら恥ずかしい。
なぜだろう？　自分だけ服を着ていないからか？

チンポを公衆の面前に晒すと捕まっちゃうわけだ。
それはそういう法律になってるわけで、チンポが恥ずかしいとか汚いとかそういう問題じゃなくて、
それは悪いことなんだよね。

なんでチンポ出して歩いちゃだめなんだろう？　別に恥ずかしくないからいいじゃん。
うまくいけば俺のディックに一目惚れした女が寄って来るかも知れないし、そしたらすばやくファックできるし、
ションベンも1ステップで済むぜ。
素っ裸で街歩いて悪い理由が見つからない。


というわけでgoto使っちゃダメよと偉い方が言ってんだから素直にそれに従えよ。
みんながgoto使わないんだからお前も使うな。社会の秩序を乱して歌舞いたつもりか？　粋なツモリ？
思考を停止しろ。gotoは使わない。思考を停止しろ。gotoは使わない思考を停止しろgotoは…………

それではハッピーファッ王！

よしわかった！これからはforやwhileでできることでも全部gotoで書くよ。

>>311　ifが抜けているよ

前方/後方ってのはあんまり関係ないのでは？
continueとかbreakの機能からの連想でそう言いたくなるのは理解できますが。

goto使いたくなるときって、だいたい同じ条件式を2回（n回）
評価したくないときじゃないかな。

>>310
そういう「法律」を認めない

>>314
ﾀﾊｰ!

そうだお前、俺の腹の中にしょうべんしろ。

>>310
ヽ(・∀・)ﾊﾞｶﾊｹｰﾝ(・∀・)ﾉ

勝手な前提と無理な比喩どころじゃねぇなｗｗｗ

まぁ、権威主義を認めるとしても…
偉い人が「gotoは絶対使ってはダメ。これはルールです。」(意訳)と
言っているということだけど、具体的なソースを示してもらえませんか？

>>317

あー、認めるとしても→認めるという前提だとしても、ね。

必死だなｗｗｗ

>>321

基本的な処理をgoto無しで書いたとしても例外処理にgotoを使ってしまう。
アルゴリズムで対処できない例外として処理を分割したいから。
人間もパソコンもデータも完璧で間違いを犯さないならgotoを排除できるかもしれない。

だから。。。構造化プログラミングてのはな(ry

ﾌﾟ

>>313

ってゆーか「例外」処理だな goto が必要と思う時

ここにも冬厨が……

>>317
おまえ面白くなーい
帰っていいよ

>>313
>　goto使いたくなるときって、だいたい同じ条件式を2回（n回）
>　評価したくないときじゃないかな。
int　count　=　0;

loop:
　　if(1){
　　}else{
　　}
　　if(count　>　10){
　　　　count++;
　　　　goto　loop;
　　}

前方へのgotoは認めません

>>329
？？？何が言いたいの？
なんでそこでわざわざgotoなんか使ってコードの可読性を下げる必要があるのか、
理解できませんが。。

「前方」って書くと>>329じゃなくて例外処理みたいな場合を思い浮かべるんだけど、どう？
前方参照、後方参照の前方という解釈だとね。

でも、まぁ、「先頭に戻る」ためのgotoを使うべき場面って、思いかないね。

とんだネタスレだな

>>333
gotoだけにな

>>293
＞だいぶ興奮しているね。悪口が書いてあっても感情的になったら駄目だよ。眠れるかな？
おかげさまで皆様の五寸釘の呪いにもめげずぐっすりと。

＞＞だとしたら酷い判断ミスだな。Cの文法に判断ミスがないとは言わせない。
＞総論は認める。だがgotoについては認めない。
＞#構造化構文＋goto有りの言語はすべて判断ミスであるとの主張なの？
パフォーマンス上の都合とか。

＞#あなたはもしかして前スレの828ですか。言っていることがとても似ている。
前スレが落ちているので確認できない。でも前スレの最後の頃からいるからそうかもしれない。

＞答えさせるばかりでなく、答えて欲しいな。>>161 への回答をお願いしたい。
名無しで答えてた。
>>172 >>182 >>184 >>186 >>187 >>189 >>193 ここらへん。

>>303
変数のエイリアシングの事？

>>304
＞「なんか偉い人が言ってるから間違いない」と思い込む
これをそのまま返せばgoto肯定派は
「偉い人が言ってるけど(全然偉くも有名でもない)俺にとって不愉快な話だから、間違っているに違いない」と思い込んでるわけだ。
俺の書いた>>266の後半部分に答えられるか？

＞ところで君、オブジェクト指向に関して
＞どこかのｽﾚで同様の頓珍漢な会話してなかった？
自らトンチンカンだと思って話す奴はいないだろう。
goto肯定派は自分でトンチンカンだと思っていないだろう？

>>305
誰？引きこもり？妄想激しすぎるんじゃないの？

>>310
あんたは思考を再開したほうがいいんじゃないか（藁。
何故gotoを使ってはいけないのかもう一度よく考えろよ。

>>318
そう読めたあなたの我田引水な思考回路のソース(ファイル)を晒して下さい。

>>323
人間が間違いを犯すからgotoを排除するんですよ。

>>335
＞>>303
＞変数のエイリアシングの事？
関数型言語で言われてることだね＞副作用

>>318
"Go To Statement Considered Harmful" Edsger W. Dijkstra
http://www.acm.org/classics/oct95/

goto使い ＝ 馬鹿

＞俺の書いた>>266の後半部分に答えられるか？

(初心者ゆえ)gotoを恐れずに使い
↓
(自分のコードを見返しor他人に指摘されて)自分のgotoの使い方の間違いに気づく
↓
gotoをめったに使わなくなる(が、過去の経験から問題ない使い方も知っている)

ってのが、普通のプログラマのたどる道だと思うが。
否定原理主義の人は、こういうプロセスを踏まず、いきなり「使ってはならない」から
始まるから不自然に感じるんだろうね。そして、結果バランスを欠いた思想を持って
しまう(人もいる。>>297参照)。

(goto使い = 馬鹿) = 馬鹿の一つ覚え

>>335は、議論として、なかなかいい方向だね。
変な比喩なんか使わずに、そういう風にレスを続ければよかったのに…

>>331
>>313を読んだら分かるんで無い？

>>340
>>297の多重ループは設計上、どうしようも無い時がもしかしたら、あるかもしんない。
しかし、「一気に抜けたくなる設計」ってのは極悪じゃないか？

それと全然、関係ないのだが「普通」と言うことは軽々しく使わないほうが良い。

>>338
ありがとう。ああやはり。私の記憶は間違っていなかった。
Go To Statement Considered Harmful
の内容は単に「構造化プログラミングの提唱」だ。
「gotoは有害を引き起こす」というのは単なるキャッチコピーだ。
＃ダイクストラは自らのキャッチコピーに起因するgoto論争に嫌気がさして
＃晩年はgotoと聞いただけで不愉快になったとも聞く

一気に抜けたくなる設計

for(){
for(){
for(){
処理
if(ループを一気に抜けたい状態が発生) goto loop_exit;
}
}
}
loop_exit:
後始末


他にどーしろってーの?

>>345
後始末をしてからreturnという方法もある。
が、ここはひとつgoto禁止論者のレスを待ってみようか。

フラグ=0
for(){
for(){
for(){
処理
if(ループを一気に抜けたい状態が発生){
フラグ=1;
break;
}
}
if(フラグ) break;
}
if(フラグ) break;
}
後始末



まぢっすか？

検索処理なら単一のメソッドにしてReturnだろ普通。
getIndexとか。

>>345
reloadしたら被ってるけど。カキコしてみよ。

boolean proc() {
　boolean result = true;
　for( ; && result ; ){
　　何か処理
　　if (proc_next_nest()) {
　　　何か処理
　　} else {
　　　何か処理 /*なくてもいいけど、可能性として*/
　　　result = false;　/*for()の３項目めが実行されちゃうけど、"break;"も避けてみました*/
　　}
　　/*ここには何も書かない*/
　}
　
　if (result) {
　　正常終了処理
　} else {
　　異常時後始末
　}
　/*ここには何も書かない*/
　return result;
}

これでネスト構築、とか。ヘタレ過ぎですか？

大昔のBASICかFortranからプログラミングを始めた人がいるスレはここですか？

>>346
関数の最後以外のreturnはgotoと似たようなもんですよ

>>340
覚えているかい少年の日の事を
暖かい温もりの中で目覚めた朝を
アムロ　振り向くなアムロー！

いやすまん。なんかこの歌思い出した。
でも本当に初学者の頃を思い出してみていただきたい。
＞(初心者ゆえ)gotoを恐れずに使い
＞過去の経験から問題ない使い方も知っている)
初学者が問題ないgotoの使い方なぞ意識したりできるだろうか？
俺はベーマガのリスト打ち込んでた頃は本当に無茶苦茶だったんだが。
で、gotoの正しい使い方とは何かなんて考える間もないまま
構造化理論という世論に飲み込まれてしまったよ。

ばかもの
forの終了条件に一気に抜ける条件も加えるのじゃ

Dr.D降臨

>>353
for文は
for(i = 0; i < max; i++)
以外の形で使うことはあまり推奨されていません。

>>355
ﾊｧ?
何言ってんの？
お前ローカルルールか？

>>352
＞構造化理論という世論に飲み込まれてしまったよ。
ご愁傷様

>>343
＞>>297の多重ループは設計上、どうしようも無い時がもしかしたら、あるかもしんない。
＞しかし、「一気に抜けたくなる設計」ってのは極悪じゃないか？

>>297の前半だけ読んでね。後半はタダの皮肉だから。
(否定原理主義者には通じないみたいだけど。)

>>356
こう書けばC言語知ってる奴は一瞬で理解できるんだけど
それすら知らないとは･･･

>>359
同意。
>>355は全面的には支持できないけど、>>353は明らかに「for文の誤用」だ

>>336
＞>>318
＞そう読めたあなたの我田引水な思考回路のソース(ファイル)を晒して下さい。

うん？偉い先生は「ルールにしろ」とは言っていないってこと？
だったら、「構造化はルールであり絶対外れてはならない。」ってのはどこから出てきたんだ？
>>335が提唱しているだけ？

`>>343
＞それと全然、関係ないのだが「普通」と言うことは軽々しく使わないほうが良い。
今は促成栽培が「普通」だからねｗ
(だからgoto禁止を「ルールとして採用」するところが多いのは納得するところだ。)

>>346
＞後始末をしてからreturnという方法もある。
＞が、ここはひとつgoto禁止論者のレスを待ってみようか。
後始末を2箇所(以上)に書かなければならないことの危険性はわかるよな？

>>362
関数化する

>>361
>>344

>>363
そしてたいした意味も無く関数が増えるのか？糞コードだな。
いつもそういうコード書いてるのか？

>>365
「マクロ化する」って言っても「糞コードだな」と返すんだろう。
関数に意味が有るか無いかはそのプログラムのコンテキストに依存する問題で
一概に「意味が無い」と断ずるのは「強弁」だ。
そんなことより>>345へのレスを書いてみたらどうなんだ。

>>359
ちなみにどんな使い方をするとダメだって？

for(int i = 0, loop = TRUE; i < 100 && loop; i++){
　　for(int j = 0; j < 100 && loop; j++){
　　　　for(int h = 0; h < 100 && loop; h++){

　　　　}
　　}
}

例えばこういうこと？

>>368
たぶん、そういうことだ。しかもこの方法は、
「最内周での脱出しなければならない事象の発生以降に実行される文がある」
場合は使えない。
まあbreakすればいいんだが

そんなの、こうすればいいじゃん

LOOP: for(int i = 0; i < 100; i++){
　　for(int j = 0; j < 100; j++){
　　　　for(int h = 0; h < 100; h++){
　　　　　break LOOP;
　　　　}
　　}
}

>>370　このｽﾚﾀｲの言語はｃだぞ

#define breakex goto

>>366
そういうマクロの使い方は好きではないが、無意味な関数化よりかはましだろう。

＞関数に意味が有るか無いかはそのプログラムのコンテキストに依存する問題で
＞一概に「意味が無い」と断ずるのは「強弁」だ。
「後始末が複数になることの回避」のため(だけ)の関数化が無意味だといってるの。

コンテキストに従い関数化し、結果としてgotoがなくなるのであれば、もちろん問題
なんかあるはずが無い。例えば、「後処理」が本来呼び出し側で実行される処理であ
れば、処理をそちらに移した上でループの最内周からreturnするのは全然間違ってい
ない。ここで無理にgotoを使っても読みにくくなるだけだ。

あと、俺はアンチgoto否定論者なので、俺的には>>345は正解。

>>373
大筋は合意だが。
「後処理が本来呼び出し側で実行される処理」であるか否かの判断はなにを基準に行う。
これは「呼び出し元において、後処理に必要な情報が変数スコープとして見えているか否か」か？
見えていなければ下位関数化することに意味があり、見えていれば下位関数化することに意味が無い。
ということでよろしいか。

>>374
後処理に必要な情報がどっちの関数に「所属」しているかによる、かな？
情報を処理する責任の問題。「コーディングのテクニック」とは別問題だと
考える。

というか、>>373は「関数化」の意味を間違えてたっぽいか。
>>345のgotoをなくす方法としては、
・必要な情報を作成し、>>345のような関数を呼び、戻ってきたら作成した情報の
　後処理をする(wrapper関数作成型?)
・後処理をする関数を作成し、returnの前で必ず呼ぶ(下位関数作成型?)。
の2種類あるわけだけど、>>373は前者。>>366は後者だよね？

後者は前処理との対称性が崩れるので、俺はよろしくないと思う(マクロも同じ理由)。
まぁ、必要な情報を構造体化して、前処理も関数化すれば、問題は無いと思うが
(構造体化するのは、必要な情報の型や数が変更される場合の保守性を考えて。
この場合、「必要な情報」を処理する責任は前処理、後処理関数にある。)

ただ、その場合でも、returnの前に必ず同じ文を入れないといけないわけで、
>>362で指摘した危険性からは逃れられないね(最小化はされるけど)。
なので、こういう場合に限りgotoを使った方がよいというのが、俺の結論。

なんでもっと抽象水準を上げて考えられないかね。
>>375
＞こういう場合
それじゃ条件が限定されすぎじゃないですか？

>>345って、要するに同じ（ループを抜けるための）条件式を複数回評価するのは
保守性が悪い、あるいはエレガントじゃない、ってことでしょ。

微妙に論点が違ってる罠。

対照性か。言い事がわかってきたよ。
＞後処理に必要な情報がどっちの関数に「所属」しているかによる、かな？
＞情報を処理する責任の問題。「コーディングのテクニック」とは別問題だと
＞考える。
確かに。プログラム設計方法論の問題だ。

親関数で
　前処理関数参照
　本処理関数参照
　後処理関数参照
と順次参照するのがbetterだという見解だな。
以下の部分を良く読んでくれ。
>>345が親関数なのかそれとも本処理関数なのかのどちらにみなすか
によって、判断が違ってくる。
あなたは345が本処理関数だと思っていた。私は345が親関数だと思っていた。
どうよ？

＞ただ、その場合でも、returnの前に必ず同じ文を入れないといけないわけで、
＞>>362で指摘した危険性からは逃れられないね(最小化はされるけど)。
＞なので、こういう場合に限りgotoを使った方がよいというのが、俺の結論。
「return 後処理関数参照」でも駄目か？

ごらぁｺｰﾀﾞ！
バカな屁理屈ばっかこいてないで
とっとと仕事しろ！

あっお前のソース全部書き直しな。

長いものに巻かれたい人へ
http://pplab.snu.ac.kr/courses/PL2001/papers/p261-knuth.pdf
こっちはまだ御存命のアルゴリズムの大家だよん。
元々、クヌース先生はgoto擁護派なんだ。

有り余る時間があればgotoは不要かもしれない
差し迫る納期との戦いではgotoでやっつけ仕事もやむなし
一般人は理論より実践が大切

キチがった中年のアルゴリズムの大家とやらに巻かれると妊娠でもするのか？

>>382
さあ？。
でも偉い先生の発言が即「法律」とか「ルール」とか思う香具師もいるようだから、
選択肢を増やしてやるのも医院んじゃネ？

社会人の俺にとってはスヌース大先生よりも仕事を依頼してくるクライアントの方が格上。
クライアントの要求を満たすためならgotoでも何でも使ってやる。

マンコムの要求を満たすならバイブでも何でも使ってみたい。

君は、gotoだけでプログラムを書けるか？

>385
マンコムからのRFPを提示てくれ
検討してみる。

if文も許されるものなら。
後、普通の代入と計算と。

ｃでなら書ける。

いまどきフロー書いてるウチの職場ではgotoなど当たり前。
ラベル名が番号だったり、ラベル１コつけるのにハンコが４つ、だったりね、
あははははは・・・・

ハンコｗｗｗ

>>390
気の毒だが
当然ながらフローチャートでも構造化は出来るぞ

おお、今ってどこもフロー書いてないのか？

PAD図だろ？

>>393
せいぜいシーケンス図(?)とか
状態遷移図or表とか

>>393
書いてないよ。ところでツール使ってで書いてるんだよね。
まさかテンプレート使って手書きじゃないよね。

ここでfor文の多重ネストからgotoで抜けるとか言ってる奴ってバカ？
while文とかdo　while文とか知らないの？
頭わるーい（ｗ

恥ずかしい香具師

>>380 >>383
クヌースはA級永久戦犯。
そもそも俺はアルゴリズム厨は好きじゃない。
構造化もダイクストラが偉い先生だから有用なのではない。
法律ではなく法則だと前スレで書いた。
ルールという言葉から強制しか思い浮かばない己の心の貧しさを恥じろ。

もうなんか>>235たんはどうでもイイや。

>>394-396
いや、漏れはまだ現場を知らないアオい香具師だから・・・
どんな参考書読んでも「フロー書け」みたいな感じになってるんでね。
あのﾏﾝﾄﾞｸｾｰのが無いなら少し安心だよ

>>399
あのさあ、単に「A級永久戦犯」とか「好きじゃない」だけじゃ
なにを言ってるかが全然わかんないんだけど。
もう少し理解出来るように書いてくれないかなあ。

>>402
もう相手すんなって。

ある法則が成立するからといって、それが常に最適解を提供するとは限らない。

>>404
概出ですよ。それとも偶然の一致ですか？

前スレまで見てられるかよ。

>>402 ＝ >>403 ＝ >>305
藻舞勝てなくなるといつもそればかりだな。

>>407
なにいってるか和姦ね。
藻舞、かわりに>>399がなにいってるかを説明してくれ

俺は、>>399の最後の行で幻滅した。
散々法律と比較しておいてそれかYOｗってな。

goto を使わないよう等値に変換したときのデメリット
(実行速度の低下、不要なブレークダウンの発生、
シーケンシャルな処理の分断、etc) よりも
莫迦が goto を乱用した場合のデメリットの方が
インパクトが大きい、とでも思ってるんじゃない? >>235 って。
まあ思うのは勝手だから、放っといてあげよう。

…ふと思ったんだが、>>235 は
　　1. 最近になって構造化 COBOL に触れて感激した人
　　2. 30年前からタイムスリップしてきて、その間の議論を知らない人
のどちらかじゃないかと思うんだけど、あってる?

235はバカだが
410は論外だな。

＞莫迦が goto を乱用した場合のデメリットの方が
＞インパクトが大きい、とでも思ってるんじゃない? >>235 って。
実際、大きいよ。

同様に
・バカが意味不明な変数名をつけたときのデメリット
・バカが不用意にポインタを乱用したときのデメリット
・バカがマクロを乱用したときのデメリット
・バカがforやwhileの条件に何でもかけることを乱用したときのデメリット
・バカが不用意に3項演算子を乱用したときのデメリット
・バカがフラグ変数を乱用(多様)したときのデメリット
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット
も大きいな。

つまりは、そういう話だ。

>>410
＞goto を使わないよう等値に変換したときのデメリットよりも
＞莫迦が goto を乱用した場合のデメリットの方がインパクトが大きい、とでも思ってるんじゃない?
235ではないが、思っている。
だからこそ、goto使うべきところでは使うべきだし、それ以上にgoto誤用は絶対に防止すべきなんだ。
「goto使用禁止を規約にすることは反対」というスタンス。

＞1. 最近になって構造化 COBOL に触れて感激した人
いやベーマガとか言ってるからコボラじゃないと思うよ。
＃「構造化 COBOL」ってモジュールコンパイルできる？
＞2. 30年前からタイムスリップしてきて、その間の議論を知らない人
俺も1968から始まったgoto論議について、内容までは白根。
ただプログラミング始めてから今までのあいだに、
ああいう宗教みたいな信念が形成されたんじゃないの。

というか、一人で全部作ればいいじゃない。
今時のプログラミング環境はそれが出来るくらい秀逸でしょ。

>>412
×・バカが意味不明な変数名をつけたときのデメリット
○・バカが意味不明な識別子をつけたときのデメリット

それと
・バカがグローバル変数を乱用したときのデメリット
・バカが環境変数を乱用したときのデメリット
を是非とも追加してくれ。

結局、最後の
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット
に集約されるんだけどね。

>>414
もっと発言してくれ。
「若い」ということがどういう事であったのかを、もっと思い出したい

intは2バイトだろ？

>>416
社内失業者でつか？

>>418 だったらいいんだけどね

なんだ、ただの失業者か。

既にもう何年も前から >>414 の意見があながち無闇でもなくなってますよ。
個々のモジュールを小さく設計しておいて、腐れきったコードはばっさり捨てればそれでいい。
もちろんメンテしながら長く使えるコードを書いといたほうが生産性は高くなるわけだが
解読不能なほどまでになったものを無理に残すより、イチから作り直したほうが早い。
読めなければ他人のコードを読む必要は無い。１人で開発しているのと同じ。

営業、SE、管理職が客の言葉をプログラマーのとこまで、一字一句そのままに運んで
今すぐ修正作業にとりかかれと要求するから、プログラムはグチャグチャで納期がノビノビするんです。

今どき goto を使うなだのなんだのウダウダ言ってるのは、いわずもがなで既に過去の人。
まったく別の業界に転職するのが最善の選択肢。

>>412
・バカが保守性も解析性も悪いC言語コードを乱発したときのデメリット

これ以外は、むしろ >>412 の頭が悪くてコードを読めないんじゃないかと思うが、どうだ？

保守性とか解析性とかと goto やら他の文法的なものが関係あると思っているようじゃ、
今まで何年やってようが >>412 の履歴書は既に古紙だ。
他の業界に転職して、プログラミングは趣味にとどめておけ。

＞保守性とか解析性とかと goto やら他の文法的なものが関係あると思っているようじゃ、
＞今まで何年やってようが >>412 の履歴書は既に古紙だ。
なんかネタでも釣りでもなく、本気でこう思ってる悪寒。。。
それは把握・識別能力が常人のそれを遥かに超える天才ゆえにか、
はたまたその逆なのか........。

若い方なのではないでしょうか？
BASICやCOBOLのgotoだらけのコードを呼んだことのない人は
gotoに対して生理的な嫌悪感などは抱いていないのかもしれません。

ここはバカ大集合スレか？(´,_ゝ｀)

いま >>1 から順に読んだけど、勝手に感想を述べると
「goto を使うな」は「コメントを書け」と同じだ。
無理に goto を使わないように書き直したり、
無闇矢鱈とコメントを書けば、 むしろコードの可読性が悪くなる。
何年現場にいようとプログラミング言語の読書きができない、
言ってるバカの知能程度を晒しているだけのこと。
そんなバカを管理職にして部下をつけてると、会社があぼーんするぞ。

ほな さいなら

http://www.sessame.jp/workinggroup/WorkingGroup2/StructuredAnalysis.html

おまいらの大半はここのメイビー君だろ。

>>424
いっぱい読んだこと有るけど、生理的嫌悪など抱きませんが？
書いた人でなく、言語全体でもなく、gotoに焦点を当てる理由を聞かせて？

gotoを使わないのは手段であって目的ではない
>>424はそこを勘違いしている

>>423
＞それは把握・識別能力が常人のそれを遥かに超える天才ゆえにか、
＞はたまたその逆なのか........。
もちろん、自分のプログラムしか見たことないからに決まってるじゃん。
独りで出来るんだから、他人のプログラム解析する必要も無いわけだからな。

>>424
つまり、Ｃを使いこなせない人が自分の勝手な嫌悪感を判断基準にして
プログラムを組んでいるというわけですね？

・・・とか反論してると、反論した人はgotoを使いまくるという前提のものに再反論
してくるに100goto。あ、反論じゃないとか話題を変えて逃げるのにも150break。

素朴な疑問だがcでgoto使いまくりの奴はいるのだろうか？
いるならどのようなプログラムを書いているのか見てみたい

1関数が2000行くらいあって、その中でgotoで行き来しているプログラムなら見たことある。

さいならって書いてあるから４１８はもう来ないかな

>>421
＞解読不能なほどまでになったものを無理に残すより、イチから作り直したほうが早い。
正論だ。だがこれはコストの問題だ。「イチから作り直したほうが早い」が事実だとしても
次回の保守はどうする。また「イチから作り直したほうが早い」と言うか？
一人の人間に延々といくつかのプログラムを保守させ続けることなぞ出来はしない。

>>422
＞>>412 の頭が悪くてコードを読めないんじゃないかと思うが、どうだ？
思わない。あなたに保守不能なコードを見た経験があろうとは思えない。

>>426
＞「goto を使うな」は「コメントを書け」と同じだ。
支持。
そこまでの洞察力を持っていながら「>>422のような頓珍漢なことを言う」という事実が、
やはり「経験が無いから」という類推の根拠となっているんだ。
私が、「わかりやすいプログラムスレ」で「コメントは通常、あまり書かない」と書いたら大叩きされたが。

>>429
その手段は常にその目的に適合するのかな？
あなたがフラグを全く作成しないという力量があるなら、支持できる。

>>430
私もそう思う。

結論：場合による。
-----------------終了----------------

＞私が、「わかりやすいプログラムスレ」で「コメントは通常、あまり書かない」と書いたら大叩きされたが。

>>434のプログラムには1行毎にコメントがついていたよ。
a = 12345;　　　/* aに12345を代入する */
とかそういうの。

アセンブラ並だな。

潔癖症だが掃除が出来ずゴミ屋敷に住んでいるタイプと見た

>>428
えっと、それには歴史的な経緯がある。
1968年という大昔にダイクストラという計算機科学者が>>338の論文を書いた。
その頃のプログラミング言語は構造化構文を備えたものは
（殆ど？）無かったので当時のPGはこれを無視したようだが。
その後、ダイクストラ自らの手によるalgolを初めとして、
構造化構文を備えた言語が次々と誕生した。
またダイクストラのみならず、多数のいわゆる「伝道者」が
>>166のような援護射撃を行い、構造化プログラミングを提唱し、現在に至る。

gotoを備えていないのはメジャーな手続き型言語ではjavaだけだ。
つまりgotoは言語を超えてPG全体に関係する問題であるわけ。
構造化構文を備えていない言語を使っていたPGが
構造化構文を備えている言語の使用を余儀なくされたときから（あるいはもっと早く）
上記の論文の題名が刺激的であるという事実も拍車をかけ、
goto論争は始まった。そして今も続いている。

#記憶だけで書いてるから間違いがあったら指摘してネ

なぜgotoが憎いのか？

もう業務でC言語を使う用途は速度を要求される物ばかりだから、
Cで書く時は構造化、関数化はなるべくしないように意識をしている。
いくらコンパイラの最適化が進化したとはいえ、関数呼び出しまで最適化はしないからな。

>>440
つまり、そのgoto論争に嫌気が差して、gotoという単語を見るだけで気分が悪くなった
らしいダイクストラと同じような症状になっていると？

でも、そう考えると
＞BASICやCOBOLのgotoだらけのコードを呼んだことのない人は
が謎だなぁ…

>>428
なに今頃マヌケな事言ってんだｺｲﾂは…

「今頃」と「マヌケ」について、それぞれ解説をお願いします。

>>428
> 書いた人でなく、言語全体でもなく、gotoに焦点を当てる理由を聞かせて？
書いた人はもう居なかったり、知らない人だったり。
言語全体はgoto以外は目立った不満はなかったり。
でもそんな事よりも

gotoを使ってメンテナンス不能なプログラムを書いても
「動けばいいだろ」がまかり通ってしまう、
そんな現実に対して嫌悪感を抱いているのかもしれませんね。

まだCOBOLerだった頃の思い出なぞ含めながらのレスでした。

完全に蛇足ですが、C++使いではgoto使う人にあったことがないです。
COBOLerは(PERFORMがなかった当時の名残かもしれませんが)みなさんgotoがお好きなようで。

>>446
それは、goto以外の原因でメンテ不能に陥っているプログラムを経験したことないからでは？

>>448
あるいはそうかも知れませんね。
でも識別子などはエディタの置き換えで
わりと簡単に改善できたりします。

PGの能力が低くてgotoを悪用しているケースは
人材が不足している所では多いでしょうし、
構造的にダメなプログラムは
つじつま合わせでgotoを使っている場合もあったりと
ダメなプログラムでgotoを見かける確率が
高いのではないかと思いますよ。
で、何をしているのか見極めて直すのが結構手間がかかるんですよ。

結果、悪いプログラムでよくみるgotoは、
そんなに悪くない使い方でも生理的に嫌なものを感じる。と。

まるで2chのJava使いのようだな
可哀想なgoto

>>443　誤爆です。私は>>424ではありません。

C++等では例外を使って、関数の壁をぶち破ってプログラムの流れを変えることもできるからね。
gotoなんてまだかわいいほうだ。

>>451
いや、それはわかってるよ。
>>251が、>>424(と>>428)のレスの解釈を間違ってるんじゃネーノ？という意味。

basicでgoto使ってないのなんてあるの？

>>449
たしかにgotoが使われているプログラム全体とそれ以外を比べれば、
gotoアリの方が品質が悪い傾向にあるだろうね。
だけど、それで目を曇らせてしまうようじゃ頭が固いと言われてもしょうがないかもね。

gotoを見て「警戒する」ことと「嫌悪する」ことは全然違うことだからね。
(ぶっちゃけていうと、技術者の取るような態度ではないなぁ、と。)

>>453
・・・間違っていたかも知れません。スレ汚し失礼
#眠くて頭が動きません

>>448
＞それは、goto以外の原因でメンテ不能に陥っているプログラムを経験したことないからでは？
多分違うよ。
goto以外のクソコードも見たことはあって、クソだとも思ってるんだ。
でもgotoだけに言及するのは、gotoが見た目にも分かりやすく、批判しやすく、
広く流布している説でもあるからそう思い込んじゃってるだけだよ。
んで、トラウマになったような「気分」になってるだけ。こんな気持ちになれる
オレはスゲーぜって。たぶん>>235もそうだろうね。

>>452
スマートポインタなんかと組み合わせれば、結構安全にプログラミングできるけどね。
明示的に後始末しなければならない(忘れると不具合の原因になる)なんて、既に古い
書き方なんじゃないかと思う。

そんなgotoを適切に使えるオレはスゲーぜ、とどこが違うんだそれ。

>>455
>(ぶっちゃけていうと、技術者の取るような態度ではないなぁ、と。)

おい、そこのお前！ ちょっとこっちへ来い。
http://pc.2ch.net/test/read.cgi/prog/1070958293/l50

>>442
そんなことしても
処理速度にはほとんど影響しないよ

やはり年寄りがしがみついているのなw

>>459
別に「スゲー」ことじゃないと思うが…？

>>460
別に「プログラマのとる態度でない」でもいいよ。

>>462
私は「年寄り」かもシレンが「しがみついている」とは思わんぞ。
gotoは、無くてもプログラムは書ける。
それが証拠にここ数年のgoto使用の実績は、一行／二万行だ。

「しがみついてる」ってのは、goto否定原理主義者の苦し紛れの妄想でしょ。
だれもしがみついて無いし…

goto >>1001

>>465
たしかに書ける。
でもそれはgotoを使わない理由にはならんのでは？

gotoを使うことでシンプルになる場合もまれにある。そう言うときは使うべき。

ただ、バカがgotoを連発するとプログラムが読めなくなるので、
バカが所属する可能性のあるプロジェクトでは規約として

「goto禁止」

を明示するほうが安全。

一番安全なのはバカをプロジェクトにいれないことだが、
たまに紛れ込む場合があるからなーｗ

この程度の話ではないのかな？

>>468
>この程度の話ではないのかな？
ということで前ｽﾚの早い段階で決着したんだが
「紛れ込んできたバカ」が
終わった話をここまで引っ張ってくれるわけさ。

>>469
なるほど。よくわかった。

>>468
＞gotoを使うことでシンプルになる場合もまれにある。そう言うときは使うべき。
支持

＞ただ、バカがgotoを連発するとプログラムが読めなくなるので、
＞バカが所属する可能性のあるプロジェクトでは規約として
＞「goto禁止」
＞を明示するほうが安全。
それはコードの解析性／保守性の低減を防止する方法として、支持できない。
>>412と>>414にもあるように、「解析性／保守性の低減」を起こす要因は沢山ある。
「goto禁止を規則にすること」は「解析性／保守性の低減を防止する方法」として不充分＆不完全だ。

＞一番安全なのはバカをプロジェクトにいれないことだが、たまに紛れ込む場合があるからなーｗ
俺は入る人間の「前の仕事のソースコード」を必ずみることにしている。これで「バカの紛れ込み」を防げる。

>>469
>>234をレスする。

>>471　五面
s/414/415/
です。

＞>>412と>>414にもあるように、「解析性／保守性の低減」を起こす要因は沢山ある。

要因が他にたくさんあるからといって、(個別に)gotoを禁止してはいけない
ことの理由にはなりませんがな。

「すべからくgotoは禁止されるべきである」への反論なら一貫性が無いこと
の指摘として有効なんだけども。>>412と>>415はそういう意味だと思う。

>>473
goto禁止の目的はなに？
goto禁止の利点と欠点はなに？
#ちなみに>>415は私です

>>471
書き方がまずかったね。多分、考えてることとか方針は同じ。

「goto禁止を規則にする」ですべてが解決するわけではない。
それは重々承知してる。gotoを使わなくても読みにくいクソコードは書けるからね。
でも最低限、goto全開で何がなんだかわからないコードだけは避けられる。

漏れも前のコードくらい読んで人は選んでるけど、「OJTです。」とかいって人を
押しつけられることってないですか？毎回、1人2人は押し付けられるんだよね。
規約は主にそういう奴のためにあると思ってる。

優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
てな感じです。

プロジェクトを引っ張る立場なら当然でしょｗ

まぁ、473=412だったりするわけだが…
>>475が言いたい事を言ってくれました。

それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
逆に他の部分に悪影響が出ることを示さないと。
(まぁ、既に上のほうや前スレである程度示されていると思うし、うまく説得
すれば「なるべく使用しないことを方針にする」くらいにはできると思うけど。)

>475 プロジェクトを引っ張る立場なら当然でしょｗ

君の文章読んでいるととても上の立場で仕事してる人間には思えないな。
引っ張ってるのは足だろ。

>>475
＞ 優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
規約破っても構わないと勘違いされるほうが重大な問題引き起こすぞ。

問題を引き起こすバカは規約を守れ、ということだろ。

規約を守らず問題を起こしたら、即、さようなら。

プロジェクトのメンバーに規約を守らせることすらできなかった奴もさようなら。

>>480
そして誰もいなくなった。

>>474

http://with2ch.net/cgi-bin/pict/img-box/img20031211180242.png

ﾜﾗﾀ

>>475
＞漏れも前のコードくらい読んで人は選んでるけど、「OJTです。」とかいって人を
＞押しつけられることってないですか？毎回、1人2人は押し付けられるんだよね。
「押し付けられること」あります。// 1人2人ならいいんだが
当然、素人さんにはみっちり品質管理が必要となるわけで、
そういうときの回答は決まっています。「もう一人、面倒を見るから、管理に徹する」

＞規約は主にそういう奴のためにあると思ってる。
規約が、力量が最下位レベルの人間に合わせて作成されるのは、良くあることですね

＞優秀な奴は細かい記述規約は守らなくても許す。goto? 必要なら使え。
＞てな感じです。
姿勢は支持しますが、プロジェクトを引っ張る立場のみならず、
規約の逸脱の許可権限をきちんと取得しておくべきです
それが運用ルール上できないのなら、やはり「goto禁止を規約とすることに反対すべき」だと思いますが

>>476
＞それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
＞逆に他の部分に悪影響が出ることを示さないと。
私は逆だと思います。つまり
「goto禁止なら、goto使用が常に悪影響が出ることを示さないと」
です。

>>482　結構、かわいい子だね。何歳？

>「goto禁止なら、goto使用が常に悪影響が出ることを示さないと」
どうして「常に」なの？個別の禁止/許可ならトレードオフの話でしょ？

>>485　それはですね。
gotoについて、個々の各使用ケースにおいて、
誤用か誤用で無いかの判断の、衆目の一致が得られないから
なんです。
goto禁止反対論者間でも意見の一致を見ないというこの点が、
現在に至るまで論争が続いているという真の原因かと判断しています。
この問題が無ければ単にgoto論争は「ものわかれに終わる」となると思いますよ

規約は妥協の産物なんだから、むしろgoto禁止を規約として取り入れて
どうしても必要なときは例外として認める、のが現実的じゃない？

有象無象ひっくるめて開発してる「生産現場w」としちゃそんなとこ。

>>486
そりゃ思考停止だよ。goto禁止派と同じ間違いを犯してる。

というか、その理論で行くと、どちらも根拠を出せないんだから、
禁止にすべきかそうでないかは「決められない」ハズなんだけど、
どうして禁止すべきでないと言えるの？

fortranの計算型gotoとか算術if、cobolのalterとかも上手に使えばエレガントな
コードにはなったがたいてい禁止だった。

gotoを禁止する規約を作ることと、論理的にいいコードかどうかは別件かも？

>>487
割れ窓理論的には、gotoが地下鉄の落書きだとすると、
規約の逸脱は暴動に匹敵する治安悪化だと思うが。

シャアや黒い三連星クラスなら場合によって規約を通り越してgoto使用可。
一般層は基本的に規約通りgoto不可。ジーンがどうなったか考えろ。

ギレンザビであるプロジェクトリーダーは階級付けをちゃんとやれということだ。

わかりやすい。結論が出たなｗ

たいがい反発するのは、「僕はこんなにできるのにどうしてgotoを使わせてもらえないんですか！」かな。
そしたら「坊や(ry」かねｗ

「あのプロセスはなぜ氏(ry」がないとまずいか。

なにをいうか！gotoを規約で禁止している者がなにをいうのか！

これが・・・規約・・・

口で言うほど自由ではないのだｙｐ、gotoというものは。

ならgoto禁止。そうすればララァも喜ぶ。

「とうさんにだってlabelをつけられたことないのに！」

一気にネタスレ化の予感

とうさんはgoto拒絶症なんだ！

アムロ、フローを書いて変数表を作れ。そしてgoto禁止だ。

課長・・・こんな古い知識を・・・酸素欠乏症にかかって・・・

ラベル・・・私の好きなラベル・・・

クライアントとの戦いがまだまだ困難を極めるという時我々は
gotoを使うの使わないのでマジレスし貴重な時間を次々と失っていく・・・
寒い時代だと思わんか

gotoを使ったね！

使ってなぜ悪いか！貴様はいい、そうやって規約を守っていれば気分も晴れるんだからな！

ぼ、ぼくがそんなに安っぽい人間ですか！？

2度も使った！　例外処理でも使ったことないのに！

それが甘ったれなんだ！　gotoも使わずに一人前になった奴がどこにいるものか！

ふふふ・・・ガルマ、聞こえていたら君の規約の不幸を呪うがいい
君はよい同僚であったが、goto禁止の規約がいけないのだよ

全部ネタだろ？
マジレスだったら・・・

このプロジェクトだって規約があるだろうに・・・それを・・・gotoでジャンプするなんて・・・
すさんだねえ・・・・

サボテン:
　　砂漠に花は咲くか？

>>507
それをいうなら

サボテン：
　　砂漠に蝶は飛ぶのか？　//砂漠に飛ぶのはサボテンのトゲ

このgotoをプロジェクトリーダに届けてくれよ！　あれは、いいものだぁーーーー！！

オイラが、今までgoto文使ったほうが良いかなあ、と思ったのは、
双方向リストを非再帰で書いたときかなあ。
再帰で書いたら楽なんだけど、いろんなことが理由で、
どうしても非再帰で書かなくちゃいけないときなんか、goto文使うと
楽だし、見やすくない??
まあ、考える過程ではgoto文使って、最終的にはなんとなく使わない
ようにしているけど。（でもgoto文のほうが後で、知らぬ人が見ても
追いやすいかな。）

認めたくないものだな、若さ故の過ちというものを（まんまや）

>>488
いやどうも説得力のあるレスが書けるか否かが、心もとないのですが。理由が二つあります。

一つ目の理由
>>345のような場合があるからです。
#>>346は私ですが

二つ目の理由
まず最初に前スレの>124（私ですが）のコピペから始めます。
＞構造化プログラミングは万能かも知れないですが、
＞全ての場合において最適解であるかというと、私は懐疑的です。
#当スレ>>404にも同様の見解

この例示を前スレの>699（goto付き）と>700（構造化）で行っています。
このレスを始点とする論争は延々と前スレ終了間際まで続きました。構造化を用いた別法を何人かの人に
示してまでもらいました。ですが私は、やはり前スレ>699がベストだと判断しています。
#バグの有無ではなくて表記方法です
つまり「gotoレスでなくgotoを使用した、より良い方法が存在する場合がある（と思っているから）」です。
あるアルゴリズム（というほど大袈裟ではありませんが）の表記（コーディング）には
gotoを使うのが最適であるとの判断をPGがした場合、goto禁止規約なぞ邪魔なだけです。

#まあ「規約の逸脱が簡単に可能である」というところならば「どっちでもいい」に宗旨変えしますよ。
#三つ目の理由　gotoがあるから
##しかしまあ、なんて論理的に話が出来る人（達）だろう。前スレとは雲泥の差だ

int i,j,k;
for(i = 0; next && i < 10; i++){
for(j = 0; next && j < 10; j++){
for(k = 0; next && k < 10; k++){
処理
if(ループを一気に抜けたい状態が発生) next = 0;
}
}
}
後始末

＞「規約の逸脱が簡単に可能である」
簡単に、ではないことに気がついてもらわないと困るね。
規約ではない以上、優位さを常に提示してもらわねばな、なんつって。

>>512
まぁ、オレは>>412は個別にgotoを禁止する場合の反論にはならないよって言いたい
だけなわけだけど。

とりあえず、枕詞として
＞構造化プログラミングは万能かも知れないですが、
＞全ての場合において最適解であるかというと、私は懐疑的です。
「個別にgotoを禁止するのを是とする」かという問題の是非は、構造化が云々とは関係ない。
>>487がいみじくも仰っておられるが、「現場の判断」が重要なわけだからな。俺構造化云々
は禁止原理主義者の苦し紛れの(最後の砦としての)たわごと。当然、現場で通用する理論
でもない。(まぁ、このスレの議論を見てれば、その辺は自明だと思うが。)
あー、構造化を否定しているわけじゃないよ？(…と噛み付く人用。)

んでもって本論。
＞つまり「gotoレスでなくgotoを使用した、より良い方法が存在する場合がある（と思っているから）」です。
ここで、トレードオフとして判断を行う必要があるわけ。gotoが規制されやすいのは、その利点
が軽視されやすい(見えにくい)ってのが一番の理由なんだから。

ということで、個別にgotoを禁止するのを是とするかという問題では
＞それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
＞逆に他の部分に悪影響が出ることを示さないと。
をしないといけない、ということを納得してもらえるかな？
>>512はまさにそういう意見だよね。

＞#まあ「規約の逸脱が簡単に可能である」というところならば「どっちでもいい」に宗旨変えしますよ。
だから、ベターなのは、『「基本的に」gotoを使用しないこと』あたりとオレは思うわけだ。
個別の環境での判断として、それが必要な状況ならば、ね。

>>512
＞##しかしまあ、なんて論理的に話が出来る人（達）だろう。前スレとは雲泥の差だ
あんたの努力じゃないの？
gotoマンセー派にはあきれ返るばかりだけどさ、>>5によれば
あんたらが感情論で語らなくなったからこそ
goto否定派も話に付き合わざるを得ないんだよ。

規約が有るのは知ってるが、今まで一度も見た事が無い。
現実の規約は先輩からの口伝だけ。
基本的には結果オーライ。

> ここで、トレードオフとして判断を行う必要があるわけ。
> gotoが規制されやすいのは、その利点が軽視されやすい(見えにくい)ってのが一番の理由なんだから。

トレードオフって言葉まで出ながら次の文がまったく噛みあってないな。
gotoが規制されやすいのは利点のリターンより欠点のリスクのが大きいと
多くの人が判断するからだ。これがトレードオフ。

利点はさんざんgoto肯定派が書いてくれているし、
欠点もgoto否定派が沢山書いているのであえて書かないが。

>>518
＞多くの人が判断するからだ。これがトレードオフ。
「一番の理由なんだから」、逆に利点をちゃんと説明しなければならないわけね。
んで、>>471, >>473に続く

＞規約が有るのは知ってるが、今まで一度も見た事が無い。
大きい企業とか「昔」先進的ｗなひとがいただけなところだと
これが結構あるんだなぁ…(もちろんgotoだけじゃない。)

>>516
いやぁ、照れるな。

永久ループっしょ？
トレードオフの結果は人によりけりっしょ？

そうじゃなくて、環境や状況によりけり、とも言えるよ。

「間違ったgotoの使用法」はあると思うが、それは「間違ったクラス設計」と同じようなものだ。
「間違ったクラス設計をする馬鹿がいるから、クラス使用禁止」は「間違った努力」だと思うぞ。

結局、gotoの肯定禁止が技術力の高低の話に摩り替わっちゃうのが長期化の原因
2chの技術系では良くある展開だけどさ

>>524
gotoはその反省として構造化構文ができたが
クラスにはより進歩した方法は提唱されてない。

gotoを使わなければほぼ80点が取れるのに
100点を取るために頻繁に0点を取る可能性と格闘するのは
間違った努力だと思うゾ！

結局、goto使いたがる香具師は自称スーパープログラマーばかりでないの？
ホントのスーパーな人達はgotoなんざ使わなくてもスマートなコードが書けるって。
脳の造りが根本的に違う、って感じだからYO！

　　　　　　　　　　　本物のプログラマはgotoを恐れずに使う。

いまさらgoto かよ

>>515
#「構造化とgotoはある意味で、対立概念である」という理解をしています。

＞「現場の判断」が重要なわけだからな。
全面的に支持します。禿同

＞＞それでもやっぱりgoto禁止反対なら、goto禁止がまったく効果が無いことを示すか、
＞＞逆に他の部分に悪影響が出ることを示さないと。
＞をしないといけない、ということを納得してもらえるかな？
うーん。少し考えてみましたが、これは出自の違いなのかもしれません。
最初から構造化言語を使ってプログラミングしている者と、そうでない者です。
非構造化言語でプログラミングを始めた私は構造化言語を使い始めて
「わかりやすくなってきて嬉しい。でもgotoの使い道はまだあるな。有限状態遷移はgotoがベストだし」
の心象であったのですが、goto禁止規約化などと聞いて反対しました。
しかしながら「goto禁止がまったく効果が無いことを示す」とか「逆に他の部分に悪影響が出ることを示す」
などとの説明責任／立証責任がgoto禁止規約化反対をする側にあるとは思えないのです。
「最初に覚えた言語が構造化言語である人はその様に判断するのだろうか」などとも思います。
#まあ「昔から使っているものを何で禁止するのか」という素朴な疑問もありますが

>>516　少し泣いてしまいました。（本当に涙が出たわけではないのですが）

>>527
goto禁止するとホントのスーパーな人達でないとまともなコードがかけなくなってしまうので困るだろ。

>>531
goto推奨するとまったく無能な人がコードを書き散らすので困るだろ？

推奨する奴なんているのか！？

goto使用許可証を持ってる奴以外は使っちゃダメ！

プログラマめんｋｙ（ｒｙ

>>530
＞説明責任／立証責任がgoto禁止規約化反対をする側にあるとは思えないのです
少なくともこのスレで説明責任／立証責任を先に求めてきたのはgoto禁止反対派


＞最初に覚えた言語が構造化言語である人はその様に判断するのだろうか
SA >>266.

＞昔から使っているものを何で禁止するのか
SA >>268

>>235たんｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!
相変わらず、どうでもいいところばかりレスするね！！

出自で逃げられたら元COBOLerなんてどうなるんだろう
．．．考えるだに怖ろしい

初心者時代はgoto使ったことなかったけど、あるコードでエラー処理を後ろにまとめる
使い方に感銘を受けてgoto使うようになりましたが。

>>539
その考え方が、C++でさらに洗練されてexception(例外)になっています。

VBでつか?(w

>>537
どこにレスして欲しいのか示せよ。

>>539
VBのOn Error GoToじゃないだろうな？あれはgotoであってgotoではないぞ。

>>540
違います。まず向かう方向が違う。

>>541
Will you marry me?

>>542
ここは、Cのスレですが？

setjmp()/longjmp()でわなかろーか（＾＾；；>>540

>>542
自分で読めよｗ。2日レスしなかったら置いてかれたか？ｗｗ

>>545
それもある。

>>544
さっきから非構造化言語の話やらなにやら出ているようだし、
Cならではの話題は今の所は特になさそうだが(つまり手続き型言語一般に通じるとして)。

>>546
どうでもいいところばかりと言われたからな。
俺のレスしたい所にレスするだけで不満なら
レスして欲しい所を明示しろというまでだ。

別に>>235にレスしろとは言ってないし。読みきれないなら黙ってたら？

>>546
＞2日レスしなかったら置いてかれたか？ｗｗ
つーかよ、俺自身何日レスしてないのかよくわからないのに
いちいち調べるお前の粘着体質に驚きの色を隠せません。
もしかして俺のレスを楽しみに指折り数えていてくれたのか？

>>548
でも、gotoとVBのon error gotoは(使ったことないからよくわからんけど)違うんでしょ？
関係ないものをわざわざ持ち出す必要はないのでは？

>>549
＞537 ＞537 ＞537 ＞537 ＞537 ＞537 ＞537 ＞537 ＞537 ＞537

>>551
gotoってキーワードだけで同一視して語る奴が出てくると混乱の元だからな、
混乱の芽は早いうちに摘み取るのがモットーだ。

混乱しているのは、542だろう。

>>550
まぁ、このスレに欠かせないキャラクターだからな。
>>407のレスのあとどうしていたのかと心配していたわけだ。

goto許容派は好きなおかずは先に食べるだろ？
goto禁止派は好きなおかずは最後に残すだろ？

どうだ？

バランスよく食べます。

そのときどきによる。

>>554
妄想が激しすぎると禿げるぞ。
禿げはOOの達人の証だから勲章だがな。

>>556-557
スレの内容を汲んだ秀逸なレスだな。

>>558
あれ？違うの？
ごめん。レスする時間がいつもどおりだから名前入れ忘れたのかと思った。

>>559
そう、バランスよくとか場合によるとか書きながら一番初めにがっついてる図が目に浮かぶあたりが。

>>561
妄想妄想ｗｗｗ

なんだか、妄想が激しい人が居るようで。

>>560
みごとなくらいにほぼぴったりの午前１時１５分前後に
否定を書き込んでもなんだかきな臭い気がするが俺じゃない。

てか俺>>560のレスの時間みて書き込んでるな。
週末で疲れてるんだ。

また間違えてる。
>>560じゃなくて>>554だな。

というわけで
http://pc.2ch.net/test/read.cgi/prog/1036336572/l50

>>530
＞「goto禁止がまったく効果が無いことを示す」とか「逆に他の部分に悪影響が出ることを示す」
＞などとの説明責任／立証責任がgoto禁止規約化反対をする側にあるとは思えないのです。
禁止→原則禁止と規制を緩和するためでいいなら、gotoの利点を説くというのも有効。
だけど、「goto禁止」は禁止というなら上記を立証する必要があると思うよ。
(そして、それはかなり無理筋であり、goto禁止を強弁している原理主義者と同じ道。)

あと、構造化構文以外の構文は、構造化(が実現しないこと)を補うためにあるんだよ。
構造化プログラミング自体が完璧ではないことは、>>251自身も言ってることだよね。

いっこうに進展してないね。
同じことばかり繰り返してる
もうやめたら？
goto 1001

while((all != yes_goto) && (all != no_goto));

>>526
＞gotoを使わなければほぼ80点が取れるのに
＞100点を取るために頻繁に0点を取る可能性と格闘するのは間違った努力だと思うゾ！
正しい様ですが、重大な錯誤が二つ存在します。
一つ目「頻繁に」です。gotoの使用頻度は、関数数ベースで0.1%程度ですよ。#「私の場合」ですが
二つ目「gotoを使わなければ60点しか取れないので、80点を取るためにgotoを使う」のですが

>>567
無理筋かも知れないけど少し書いてみますか。
「goto禁止がまったく効果が無いことを示す」
・スパゲッティを完全に防止できる。だが単にそれだけである。
　またレビューを行うことでそれ以上の効果を期待できる（その他の品質低下要素も防止できる）。
　元来、規約の存在理由は「コードの均質化」であって「品質低下の防止」ではない。
「逆に他の部分に悪影響が出ることを示す」
・フラグ変数の乱用を招く（制御結合を招く）
・関数の肥大化　
　#これは「構造化構文により論理構造の見通しが良くなっている」という利点の、裏返しの欠点です

うむむ。やはりgoto論争の結論は「goto誤用をする人間を、goto誤用をしない人間にする」以外に
ないような気がしてきました。いや「goto誤用」というのは、単にわかりやすい氷山の一角であって、
「プログラムを書くスキルの無い人間にプログラムを書かせる」という作業環境が原因であるのでしょう。
上記の「無理筋の理由」の真の元凶は「プログラム設計能力の欠如/不足」であるからです。
#経営側からは「そんなに教育投資する余裕は無い」という返答がいつも返ってきます。
#「余裕が無いという状況」を、改善する予定があるのか否かを聞きたいものです。
、
＞構造化構文以外の構文は、構造化(が実現しないこと)を補うためにあるんだよ。
continue／break／(途中での)return 等ですね。
#do while 構文は微妙なところ。(もともとの構造化にはなかったような気が)

>>569
笑いました。無限ループを書くことに心理的な抵抗はありましたか？

末尾再帰にgotoは必須ですよ

goto or not goto, it is no longer a problem.

色んな場面でCソースを吐くツールとか作らない？
そんなとき、プログラムのフロー制御についgoto 使わない？


のかな？

お前ら過去に散々なされた議論の劣化コピーばら撒いて楽しいか？

>574
藻前にとっては過去かもしれないが
此処等の香具師には違うんだって

いい加減自己中心的なものの考え方、改めたら？

>>573
だから、switchにしろって。

>>575
事故中ってなんだよｗ
もし本当に理解を深めたいならまず過去の議論を先にフォローするのが筋だろ。
それをやらずに議論したって意味ないだろ。
そんなの唯Googleのキャッシュを汚すだけの雑談だ。

>>577
それってこの掲示板だけでいいの？
「過去の議論」ってのがいつ始まったか知っていれば
全部なんて言えないはずだけど

>>251

> 以下は俺の意見
> 「大きな事故を引き起こす」ってのは「gotoの誤用」が原因の一つになりうることを認める。
> しかし「gotoの誤用」は「大きな事故を引き起こす」原因群の最大の悪玉ではない。
> また「gotoの誤用」を起こさないための仕組みとして「goto使用禁止」を選択するのは不適切だろう。
> #大きな事故を引き起こさない事がそんなに重要ならば、
> #goto使用禁止を叫ぶより、もっと有効な行動があるのではないか

#goto使用禁止を叫ぶより、もっと有効な行動を以下に明示する。

どうしてもgotoを使いたい時は例外処理 try-catch statementをgoto文変わりにする。
for, whileの多重ループの脱出, switchなどの脱出にはラベルつきbreak, ラベルつきcontinueを使う。

おはよう日本
>>570
＞gotoの使用頻度は、関数数ベースで0.1%程度ですよ。#「私の場合」ですが
ほんとうに統計とった？
それに元々の数は関係ないって言ってるのわかるよね？
一個あるだけで増殖する危険性があんだよ。

＞gotoを使わなければ60点しか取れないので、80点を取るためにgotoを使う
じゃあ60点でいいんじゃね？60点があんたらの点数なんだよ。
背伸びして80点目指して０点の危険性ばら撒かれたら困る。

>>573
>>280の最後

>>579
＞どうしてもgotoを使いたい時は例外処理 try-catch statementをgoto文変わりにする。
本当に例外処理に使うならいいけどよ、
例外処理以外にtryブロックを使うのはgotoの乱用に匹敵する悪行だと思うけどどうよ？

>>578
>それってこの掲示板だけでいいの？
誰もそんなことは言ってないが。

>全部なんて言えないはずだけど
誰もそんなことは言ってないが。

ちょっと検索してみればここでやってる議論になんら新規性がないことがわかるよ。
このレスさえもなｗ

>>579
「例外処理 try-catch statement」「ラベルつきbreak」「ラベルつきcontinue」
なんてもんはｃにはねえんだ

Cもわかってない人が多いみたいですねぇ。

>>577　雑談じゃあいけないのか

>>584
Cでgotoを使わない理由を考察するスレのCはComputer、Cyber、Creator、CP/MのCなのです。

C → 視力検査に使うO の一部が開いている Open O → OO

OOにgotoは無用

疲れてるんなら休んどけ。

>>581
性能劣化も激しいからな。

結局、
たばこ嫌いな人 VS たばこ吸いたい人

と同じぢゃ。
吸っていない人までの健康を害するとかで、禁止されとる。
吸いたい人は肩身が狭いのう。。。

わしはgoto使うがの。

goto使わなくても０点にするのは簡単

>>591
それはgotoを使う理由にならんぞ
もっともgoto使っただけで 0点だ、と言ってる香具師も同類だが

家の子があそこの子より劣っているってゆーの?きーっ!!
運動会の駆けっこ反対!!

って事?
(gotoうまく使えない人がきーっ!!してるだけ)

Cでgotoを使わない理由

Java使いだから。
なんですかgotoって?

Cでgotoを使わない理由?
使いますよ。
/* $Id: main.cpp,v 1.8 2003/12/13 02:55:45 goto Exp $ */

>>235は果てしなく馬鹿だってことがこのスレの結論です

Cでgotoを使わない理由?

gotoはVBしかできないしなぁ。
katoやsaitoはCで使っても大丈夫。

>516
＞＞##しかしまあ、なんて論理的に話が出来る人（達）だろう。前スレとは雲泥の差だ
＞あんたの努力じゃないの？

バカとアホが褒めあってるよ

>>593
>(gotoうまく使えない人がきーっ!!してるだけ)

「うまく使える」の定義をｷﾎﾞﾝ

600 get!

いいじゃん、別に2chだし。
悔しかったら全部goto文で書いてみろ。
関数の呼び出しもwhile文も使っちゃだめだ。まあmain() ぐらいは使ってもいいけど。
あとみんなgotoだ。

for 文を goto で実装する。

　　i = 0
hajime:
　　message = "回数 = ";
　　times = i;
　　goto print:
modoru:
　　++i;
　　if(i < 10)
　　　　goto hajime;
　　goto end;

print:
　　printf("%s%d\n", message, times);


こんな感じか。あ、printf 関数は使っちゃいけないんだ。
表示部分も関数なしで書かなきゃ > 宿題。

>>601
printf の下に goto modoru; がいるだろ。

こんなに面倒だから goto は使わない方がいいんだね。

>>601
ふーん、goto 使う派は、こんなコード書いてるんだあ。

頭いいんですね。

自画自賛してどーすんのよｗ

下手ですね。for文を正しく理解していますか。こう書くものです。
　　times = 0;
　　message = "回数 = ";
modoru:
　　if ( times > 10 ) goto end;
　　printf("%s%d\n", message, times++);
　　goto modoru;
end:
もちろん冗談ですが。

>>607
ステキ！！

だが、Cの欠陥としてはPascalにある手続き内手続きの不備を指摘しなくてはなるまい。
多重ループだのなんだのは、ローカルな関数としてくくり出せればいい。
PL/IにすらあるのにCにないのが欠陥だろう。

>>609
実装を知らない厨房ハケーン!

>>607
正解はこう。

i = 0; for_1: if (!(i < 10)) goto for_end_1; i++; {
　　printf("i = %d\n", i);
} goto for_1; for_end_1:;

>>609
関数内関数は変数スコープ制御にも大きな利点がありますからね。
#言語規格策定委員会（？）の一部にそのような動きがあったとか無かったとか

>>611
どこがちがうねん

>>612
基本的にＣは機械非依存のアセンブラとして設計された。
当然速度優先の設計となる。
必然性が無く、効率を落とすような概念は全て切り捨てる。
当たり前のこと。

俺はgoto避けるために変なコーディングする奴がムカツク。
あいつらgoto使わなかったらなにしてもいいと思ってやがる。

next_1にして欲しかったな。

>>615
規約に「変なコーディングしない」という項目を入れるべきだな。

>>614
であればCでgotoを使うのは全然かまわないということですね。ありがとうございます。

学生はもう冬休みなのか？うらやましいな。
俺も自作自演でスレを盛り上げたい。

もし自作自演でなければ日本のソフトウェア業界は本当に危ないな。

自分の主張が通らない
↓
相手が自作自演してしてるからそう見えるだけだ！

典型的な負け犬の言い訳ですなｗｗ

>>620
だがよ、普通にプログラム組んでたらgotoの使用は身長にならざるを得ない事くらいすぐに覚える。
それを必要だから使うみたいな意見のやつがこんなに大多数だとはとても信じられんよ。

俺はgoto使うべきだと思った時でも本当に使っていいか丸一日悩んだりするぞ。
軽率に使って浪費する時間はその何十倍にもなると思ってるからな。
ここのやつらにはそういうプロセスが無さそうなのだ。
そんな程度の低い奴もしくは極端に程度の高い奴ばかりだとは思えん。

gotoは使う方も読む方も慎重になるから、バグ防止に役立つ。

>>621
一日悩むほど変なプログラムを書いているのか。
よっぽどセンスのないプログラム環境で育ったんだろう。

>235 日本のソフトウェア業界は本当に危ないな。
そんなことは無い。
おまえがいなくなるだけでもかなり違うとおもう。
消えてくれ。

２３５ってよほどレベルの低いコードを書いてるんだNE!

>>622
ならない。
使う側は慎重にならない奴らが大勢いる事がこのスレで証明された。
読む側ではgotoに気を取られ肝心な部分を見落とす可能性が高まる。

>>623
おまえがよほど文章の意味を考えるセンスがない事はわかった。
何も考えずに汚いコードを書き散らしている事も。

てか自演うざいって明言しないとわからない？

もういいや。
せっかくの休日までこんな馬鹿のために不愉快になる事ないから。

粘着君。お前の勝ち。
一生自演で2ch内だけで勝ってろボケ。

>>626
また妄想癖がでてるなぁ。
いろんなタイプのコードに触って育ってれば、問題が出るかどうかはコード触れば
だいたいわかるだろ。
まぁ、「goto禁止」という教えが絶対らしいからしょうがないか。

>>627
また妄想君か？それとも2ch初心者か？
まーどうでもいいけど。

さてさて、
＞使う側は慎重にならない奴らが大勢いる事がこのスレで証明された。
＞読む側ではgotoに気を取られ肝心な部分を見落とす可能性が高まる。
この2つの文に、goto否定原理主義者が持つ「勝手な前提」がいっぱい詰まってますね。

>>607
下手ですね。for文を正しく理解していますか。こう書くものです。
　　times = 0;
　　message = "回数 = ";
　　goto check;
loop:
　　printf("%s%d\n", message, times);
　　++times;
check:
　　if ( times < 10 ) goto loop;
もちろん冗談ですが。

漏れのコンパイラは最適化したらこんなコードを吐いて下さいました。

　　times = 0;
　　message = "回数 = ";
　　//goto check;
loop:
　　printf("%s%d\n", message, times);
　　++times;
//check:
　　if (times < 10) goto loop;

もちろん冗談ですが。

へ〜
そのコンパイラって、初期値が10とかだと何も作らなくなるのかな？

>>632
笑いました。もちろんそれもアリです。for文が継続条件事前判定型反復構文であることから、
まず、判定を行うのが正しいわけで、その判定を先頭に書くのが通例だと思いこんでいました。
判定を最後に持っていって、最初にそこに飛ぶという手ですか。
#冗談には「冗談返し」というわけね

>>634

void check_loop()
{
　　char *message = "回数 = ";
　　for (int times = 10; times < 10; times++)
　　{
　　　　printf("%s%d", message, times);
　　}
}

↓

PUBLIC?check_loop@@YAXXZ　　; check_loop
_TEXTSEGMENT
?check_loop@@YAXXZ PROC NEAR　; check_loop, COMDAT
　　ret 0
?check_loop@@YAXXZ ENDP ; check_loop
_TEXTENDS

となりますタ。

gotoを使うと最適化が阻害されるから使ってはいけない…という主張かな？
新展開？

>>637
最適化するとforブロック自体が消滅して、「意味が無い関数があるよ」ってエラーが出ているだけだと思うけど

エラーなのか？

>>637
最適化が阻害されるといっても、>>345と>>368とでは前者の方が
速いと思うぞ。
ループ自体は速い方がいいが、その脱出は速くなくてもいいし。

gotoが阻害する最適化って何がある？とりあえず思いつくのは
レジスタ割付ぐらいだけど。

ほんとうは、goto誤用も重大な問題ではないのです。#ここで読むのをやめないで下さいね
>>150にも書きましたが
「（混沌に）秩序をもたらす」のは「構造化プログラム設計」であって「構造化コード」ではない
ってのが本音です。
関数のサイズが30行位迄なら、その中でgotoが多用されていても読めば判るものです。
また、そのサイズなら関数レベルのリファクタリングも容易です。
何百行（あるいはそれ以上）もある関数を作って、そこでgoto誤用をしていたら、
そんなコードは保守なぞ出来るはずがありません。
goto誤用が混沌の発生源みたいに言われますが、実のところ「そんな長大な関数を設計する」のが、
設計ミスという名の「本当の混沌の発生源」です。
「スパゲティで保守できない」というのはとても判りやすい表現です。
ですがスパゲティにならない一番簡単な方法として、「規約でgoto使用禁止にする」ことを選択するのは、
問題の本質に目を背けた愚かしい行為でしょう。
「goto禁止規約」は、既存コードが保守できないという事実の本当の原因が、果たして本当にgotoを使用して
いるからなのか、それとも別に真の原因があるのかを、考える労力を惜しんだ結果だとしか思えません。
「規約におけるgoto禁止の有無」は「その組織が問題の本質を理解出来る組織であるか否か」
の試金石の一つです。

gotoを使うか使わないかは大した問題ではない
gotoを禁止しているかしていないかは結構、重要な問題である

じゃ、「構造化プログラム設計」とgotoの両立について語ってもらいましょうか。

>>642
>>150を読んでください

>>150に書いてあるのは設計とコーディングは分けて考えるべきだ
って事だけだと思うんだけど。
なので構造化プログラム設計を前提とした、許されるgotoの使い方に
ついて語って欲しいのだが。

>>644
私が考える「許されるgotoの使い方」は>>293に書きました
「分けて考えるべきだ」との主張なので、「構造化プログラム設計を前提」としているわけではありません。

>>644
>>512にも書いています。内容は同様？です。

>多重ネストからのネスト直後への脱出と有限状態遷移の表現だ。それ以外は全部誤用だ。曖昧かな？
>#前者は、gotoでなくreturnを使うほうがベターである場合も多い。

多重ループ抜け以外は「場合による」ってことですかね?
しかし、途中returnも場合によってはありなんてルールにしたら混乱しませんか?
自分がルールブックな自己完結な事なら問題なさそうですが、明文化できないと
それこそ「考える労力を惜しんだ結果」なのではないかと思いますが。
>>251さんとこは全部明文化しているのですか?

混乱する人が多そうなときはgotoを禁止する(手間かけてもいいなら、メンバーごとに
許可・禁止する)。コーディングとプロジェクト運用も分けて考えよう。

「犯罪者は、ココは管理されていない、警戒心が薄いということを感じ取って
犯罪に走るわけですね。」TVタックルの割れ窓理論の解説VTRより。
gotoも同じ？

>混乱する人が多そうなときはgotoを禁止する

よく判らないのですが、ルールが曖昧なことによる混乱と明確に書
かれたルールを理解できない人が居た場合を混同していませんか?
メンバーごとに許可制しなければならないのも暗黙の了解に頼った
曖昧な部分があるからではないですか?

>かれたルールを理解できない人が居た場合を混同していませんか?
「goto禁止」を理解できないPGがいる場合？？？？
「ルール」にするなら曖昧にするな、というのは正論だね。
だから、明確(goto禁止みたいな)にする必要がある。

>メンバーごとに許可制しなければならないのも暗黙の了解に頼った
暗黙の了解？？？？「ルール」が？

オレも言ってることが良く分からないです。

>>647
途中returnは禁止事項でも制限事項でもありません。規約そのものは少量です。
混乱を避けるためにもコードレビューは必須です。
プロジェクト毎にあるいはプログラム毎にコードの品質特性の優先順位を決めておきます。
ほとんどの場合「解析性」が最優先ですが
レビューはその優先順位を前提として議論します。

>暗黙の了解？？？？「ルール」が？

ルールのほうでは無く、メンバーごとに許可制にすることについて
です。おそらく過去に実績があるので判ってくれているだろう程度
の認識で判断するのではないかと思いました。表現が良くなかった
ですね。

>混乱を避けるためにもコードレビューは必須です。

結局、これになるんですかね?
goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。

>>653
＞goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。
その種の見解についての反論は何度も書いていますので、繰り返しません。
#>>641もその一つです。

＞ルールのほうでは無く、メンバーごとに許可制にすることについて
もちろん、その人にgoto使わせてダイジョウブかはプロジェクトリーダ(など)が
決めるんだよ。場合によってはコードレビューや過去のコードを参考にして。
goto以外のルールを適用するかどうかも同様。

で、プロジェクトリーダに無能な人が付きそうだと心配するなら、もう一つ上のレベル
(部とか事業所とか会社全体とか)で決める。決める人は決める日とで、個別に規制
するのか、一律に規制するのかを決定する(分かってると思うけど、gotoに限った話
じゃないよ？)。

これが、「運用で」の意味。

＞goto禁止とわりきるほうが問題発生率が低そうに思えるのですが。
goto以外は？基準が曖昧じゃない？(もしくはC言語禁止？ｗ)
･･･と自己矛盾しているように見える。オレにはね。

>その種の見解についての反論は何度も書いていますので、繰り返しません。

了解です。
内容には納得できませんでしたが。

>goto以外は？基準が曖昧じゃない？(もしくはC言語禁止？ｗ)

gotoスレなのでgoto禁止をルールの一例として取り上げたまでですが。
一部分でしかないの曖昧といえば、たしかに曖昧ですが。。。。。。

んじゃ、>>412、>>415について、全て「明確な」基準が有ると？
「運用でなく一般的に」そう言えるというなら、個々人の能力を考慮しなくてもイイ基準なんだよね？

あ、>>412、>>415は、例えばの話で、それ以外にも有ると思うよ。

いろいろな処理の中断条件があって、
中断する時は必ず何かのオブジェクトを破棄する必要がある場合どうするの？
いちいち中断用の関数にオブジェクト渡すの？

>>641
CPUのエミュレーションのコードで
インストラクションをそれぞれの動作に振り分けるswitchを含む関数が
どうしても大きくなってしまいます。
どうやって分割しましょう？
関数ポインタは遅くなるので嫌です。

>その人にgoto使わせてダイジョウブかはプロジェクトリーダ(など)が
決めるんだよ。

開発フェーズになれば数百人がかかわるだろ。
そんなことは可能なのか？
とても現実的には思えないけど。

サイズが合わない人は、ソックタッチでコンドームを固定するといいらしいぞ。

>>662
お前は２枚重ねだよな。
早漏だし。

>>661
選択肢は三つある。
・一律禁止
・それぞれのサブシステム(モジュール)のチームリーダーに一任する
・(暗黙に)個々人とチームリーダーにまかせる

こういう人間系がちゃんと出来てないところは、goto禁止したって結局ダメ。
まぁ、「ダメということが分かってる」なら、goto一律禁止したほうが良いわけだが…

>>660
関数サイズを行数で表現したのは「それが一番わかりやすいだろう」と判断したからで、本意ではありません
関数のサイズを行数で測るのは不適切です。
何で測るのが適切かというと関数内の識別子の種類数であろうと考えています。
それでも長いですか？。

さらに書きますか。それぞれのインストラクションに対する制御の流れの交錯が無いのなら、その種の関数は
「情報的強度を持つ」と表現されます。
これは「概念とかデータ構造とか資源を一関数内に隔離する」という目的で設計されます。
分割の必要は無いと考えます。悪い設計ではありません。
#プログラム設計相談室回答者をやるのも本意ではないのですが。

コーダに相談してもご覧のとおりのまぬけぶりだしな。

いつまでぐだぐだ言ってるんだ。
どうでもいいじゃん、こんなこと。

>>667
って、ageるなよ・・・

あいかわらず自作自演続いてるのか
なんか可哀想に思えてくるな

>>669
俺は、>>235のほうが哀れだよ…(ノД`)ﾟ｡

電車で電車で電車で電車で
ｇｏｔｏ　ｇｏｔｏ

>>670
お前>>669が>>235だと思ってるんだろｸｽｸｽ

お前は被害妄想で頭がおかしくなって死ぬんだぞｸｽｸｽ

お前が気づいていなくても俺はあちこちのスレにいるぞｸｽｸｽ

何しろお前の意見に反対してる奴はみんな俺だからなｸｽｸｽ

毎日ご苦労様です

そういえば、「割れ窓」についての議論は深まらないの？
gotoを安易に使える環境では、初心者も気軽にgotoを使ってしまうゆえ、
「割れ窓」理論により、少しずつとはいえ悪い方向に落ちていく、というのは
結構うなずけるんだが。そして結局組織全体の、もしくは、世界全体の技術力が
落ちていくわけでしょ。

上のほうの議論だと、どこまでが「割れ窓」か、という線引きが難しそうだけど、
現実だってそうなわけで、gotoが本当に「割れ窓」かどうかを議論するのは
有用なことだと思うよ。

PG界のジュリアーノは君だ！。。。とか？

>>674
お前は割れ窓理論を誤解している

そうか？

「ココは規制がゆるいから自由に(gotoを使って)やろう」と思われるんだぞ？
んで、「こういうコードが許されるんだから、俺も」と広まっていく。
結果全体的なレベルが下がる。

>>676
やっぱり誤解してる

そして、どこを誤解しているかを言わない、と。典型的な逃げだな。

割れ窓を見る犯罪者（予備軍）など存在しない

どうしてそう思うの？

>>678
「gotoが割れ窓かどうか」などという質問はばかげてる

あぁそうか、なぜばかげているかがわからんのだな。
「gotoは割れ窓ではない」として考えを進めてみろ。

お前らあほか？
お前の記憶マジックナンバいくつだ？おい

記憶マジックナンバ

水の流れは同じに見えて同じにあらず

絵描きにも2種類ある
　毎回異なる事が要求される芸術家と
　毎回同じ事が要求される職人と

しかし、どちらも同じ絵描きだ。2種類あると思うのもまた便益にすぎないといえる


プログラマも、労働を要求されるプログラマと技を要求されるプログラマに別けられるのかもしれないし、それも無意味な区別かもしれない。

gotoがあるなら、あるようい使えばいいし、なければないように使えばいい。
所詮道具で、道具は道具以上ではないんだ。

そんなところにプライドまで持ち出す方が恥ずかしいとも思えるし、また恥ずかしいと思う方が恥ずかしいのかもしれない。

いくら気持ちいいとは言われても
オナホを使うのは人としてどうかと思うので私は使わない

>>683
短期記憶（チャンク）のこと？そりゃ７±２だけど
それがどんな関係があるの？

割れ窓云々は別にしても
>>676
「ということにしたい」気持ちは伝わってきます。ﾋﾞﾝﾋﾞﾝ。

>>685
「まったく関係ない話をし出したかと思っていたら
　『〜も同じです』で話を繋げる手法」の多くは
1) 単なる喩え話をしたい、或いは 2)やっぱり関係ない話、の
どちらかだと常々思っていたんですが、この場合は
前者でしたか。

int function(...) {
void* handle;
void* handle2;

if ((handle=create(...)) != NULL) {

if ((handle2=create2(handle, ...)) != NULL) {

if ((handle3=create3(handle2, ...)) != NULL) {
int v=getValue(handle3);

destory(handle3);
destory(handle2);
destory(handle);

return v;
}

destory(handle2);

}

destory(handle);

}

return 0;
}

int function(...) {
void* handle=NULL;
void* handle2=NULL;
void* handle3=NULL;

if ((handle=create(...)) == NULL) goto error;
if ((handle2=create2(handle, ...)) == NULL) goto error;
if ((handle3=create3(handle2, ...)) == NULL) goto error;

int v=getValue(handle3);

destory(handle3);
destory(handle2);
destory(handle);

return v;

error:

destory(handle3);
destory(handle2);
destory(handle);

return 0;
}

どちらが見やすいだろうか・・・

パァ？

たった３個だから「どちらが見やすいだろうか」なんて迷うんだよ。

>>691 は destroy(NULL) が可能だという前提で書いていながら
>>690 をそうしないのは恣意的だ、ってのは置いといても

int function(...) {
　　void* handle=NULL;
　　void* handle2=NULL;
　　void* handle3=NULL;

　　v = 0;
　　if ((handle=create(...)) &&
　　(handle2=create2(handle, ...)) &&
　　(handle3=create3(handle2, ...))) {
　　int v = getValue(handle3);
　　}

　　destory(handle3);
　　destory(handle2);
　　destory(handle);
　　return v;
}

こうだろ。

int create3_wrapper( void* handle2, ... ){
　　int v;
　　void* handle3;
　　v = ( handle3 = create3( handle2, ...) ) ? getValue( handle3 ) : 0;
　　destory( handle3 );
　　return v:
}
int create2_wrapper( void* handle, ... ){
　　int v;
　　void* handle2;
　　v = ( handle2 = create2( handle, ...) ) ? create3_wrapper( handle2, ... ) : 0;
　　destory( handle2 );
　　return v:
}
int function(...) {
　　int v;
　　void* handle;
　　v = ( handle = create(...) ) ? create2_wrapper( handle, ... ) : 0;
　　destory( handle );
　　return v;
}

>>695
負けました
＿|￣|○

ちょっとまてよ
>>695のスタイルは常識だよね？
>>690 691 696はネタなんだよね？

1.gotoを使わないようにしている。
2.場合によってはgotoを使うが、出来れば使わない方がよいと思っている。
3.gotoを使うことに何のためらいもなく、goto不要論などｷﾆｼﾅｲ。
4.gotoは悪なので絶対に使わない。使う奴がいれば理由如何にかかわらず問答無用で叩く。

あなたは何番？

これも追加してくれ。

5.goto論議をするやつは厨房なので相手にしない。
6.NIFTYのプログラマーフォーラムにいるイタい論客にまかせる。

後藤

小学生のころBASICでgotoを使いまくっていたのが懐かしい。
if ループ条件 then goto ラベル
って感じ〜〜〜

BASICのGOTOは別にいいだろ

7. goto使う必要に迫られたことは無い

俗にスパゲッティとはgotoを使いまくってぐちゃぐちゃ
にからまってるプログラムのこと。

>>698
恥かしながら、いつもの自分の書き方です

>>704
解説をつけて下さってありがとう御座います。
「スパゲッティ」が死語になりつつあることを知りませんでした。
#typoもしてるし

>>699-700
通常は使わないが、使った方が良いと判断したら使う

例えば２重ループを脱出するとかには使えるが・・・。
その他に使う必要性はないと思われ。
その他にあるとしたら、人に解り難くするためと解釈している。

7.

Perlなら分かりやすく書けるのにヽ(´ー`)ノ

LOOP: foreach my $i (keys %hash) {
　my $nested_hash = $hash{$i};
　foreach my $j (keys %$nested_hash) {
　　last FAST_LOOP if $nested->{$j} < 0;
　　hoge();
　}
}
clean_up();

スレタイ嫁。

>>698
if の中に副作用を持つものを書きすぎるのは
わかりにくいと個人的には思う。好みの問題だが。

>>699
2.
多重ループの内側から抜け出す時に使う。
continue label; break label; が可能なら使う機会はもっと減るだろう。
有限状態遷移なプログラムを書くときにも時々使う。

有限状態遷移ではつかわねーな、それこそオブジェクト指向の得意技だし。
あ、Cでだからだめなんか。Cでやるったらステートもたしてイベントドリブンもどき
にするね。switchが汚いと思う人もいるだろうけど。gotoで実装しちゃうと後で
ステート増えたときがマンドクセェ。

おお私と同じ習慣の人がやっとあらわれたか

たとえばコマンドラインパーサ（有限状態遷移）やなんかをぜんぶgotoで実装したらすごいだろ。
もちろんgotoは使われるけど、深いモードからの脱出だけ。だから脱出に限定していいと思うぞ、
Cでのgotoは。そうそう頻繁にないけど、つかこないだ使ったのいつだっけ？

>>660
>関数ポインタは遅くなる
switchの方が関数ポインタより早いの？

>>716
>switchの方が関数ポインタより早いの？
普通、そうだろ？ 何か違うのか？

ってゆーか、gotoを使いたくなったのは以下のようなコードを見た時
　　void* handle=NULL;
　　void* handle2=NULL;
　　void* handle3=NULL;

　　handle=create(...);
　　if(handle==NULL){
　　　　エラー時処理
　　　　return -1;
　　}
　　handle2=create2(handle, ...);
　　if(handle2==NULL){
　　　　destory(handle);
　　　　エラー時処理
　　　　return -1;
　　}
　　handle3=create3(handle2, ...);
　　if(handle3==NULL){
　　　　destory(handle);
　　　　destory(handle2);
　　　　エラー時処理
　　　　return -1;
　　}

　　v = getValue(handle3);

　　destory(handle3);
　　destory(handle2);
　　destory(handle);

　　return v;

>>
そのコードはちょっと人として間違っている

>>719
うん。
３個だからまだいいけど７個のやつを見たことがある。
「自分のいつもの方法を押し通すとひどいことになるって事がわかった段階で相談しろ」
ってやつだ

>>717
極端な話、

　　switch (op) {
　　　case 0x00:
　　　　　：
　　　case 0x01:
　　　　　：
　　　　　：
　　　　　：
　　　case 0xFF:
　　　　　：
　　}

よりは

　　op_tbl[op]();

の方が早い。

>>721
関数呼び出しのコストを忘れてないか？
(inline化である程度最適化できるとはいえ)

スイッチ・関数どっちでもいいと思う。
実装やメンテのコストの方が大事。

実行スピードが気になるならアセンブラ出して比べればいいし、
他にチューニングすべきところが山ほどあるはず。（こんなことで悩む位なら）

ところが、どっちの方法を使うかでエミュレート速度がぜんぜん違ってきたりするんだよな。

>>722
op の値によっては jump を数十回繰り返す事を
忘れてないか？

>>723
>実行スピードが気になるなら
いや…そういう話をしてるわけで。
ま、コード見るよりは実測するのが常識だけどね。

>>725
switchから生成されるコードは主に
- if〜elseの羅列
- テーブルを使ったジャンプ
の２通りがある。
テーブルジャンプになった場合、関数呼び出しのコストがないため
関数テーブルを使ったものより早くなる。

どちらを生成するかは処理系に依存する。
実測だけではどちらを吐いているのかわからないので、
コードを吐かせて確認すべき。

処理系に依存させたくない場合は、
安定している関数テーブルの方を使った方がよいと思う。

718のどこがどう悪いんでつか？
この例ではgoto使ったほうがいいのでつか？
718がダメならイイ例のソース書いて。

>>718みたいなコード書くなんて
ハイパー短気な奴なんだろうなぁ

>>727
int func_with_goto()
{
　　void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
　　int v = -1;
　　
　　handle = create(...);
　　if (handle == NULL)
　　　　goto error;
　　handle2 = create2(handle, ...);
　　if (handle2 == NULL)
　　　　goto error;
　　handle3 = create3(handle2, ...);
　　if (handle3 == NULL)
　　　　goto error;
　　v = getValue(handle3);
　error:
　　if (handle3)
　　　　destory(handle3);
　　if (handle2)
　　　　destory(handle2);
　　if (handle)
　　　　destory(handle);
　　if (v == -1)
　　　　エラー時処理;
　　return v;
}

int func_without_goto()
{
　　int v = -1;
　　void *handle = create(...);
　　if (handle) {
　　　　void *handle2 = create2(handle, ...);
　　　　if (handle2) {
　　　　　　void *handle3 = create3(handle2, ...);
　　　　　　if (handle3) {
　　　　　　　　v = getValue(handle3);
　　　　　　　　destory(handle3);
　　　　　　}
　　　　　　destory(handle2);
　　　　}
　　　　destory(handle);
　　}
　　if (v == -1)
　　　　エラー時処理;
　　return v;
}

int func_without_goto2()
{
　　void *handle = NULL, *handle2 = NULL, *handle3 = NULL;
　　int v = -1;
　　if (((handle = create(...))) &&
　　　　((handle2 = create2(handle, ...))) &&
　　　　((handle3 = create3(handle2, ...)))
　　　　v = getValue(handle3);
　　else
　　　　エラー時処理;
　　if (handle3)
　　　　destory(handle3);
　　if (handle2)
　　　　destory(handle2);
　　if (handle)
　　　　destory(handle);
　　return v;
}

func_without_goto() が美しく見えるが、
エラー処理がもっと沢山増えるとネストが深くなるので、
func_with_goto() にしたくなるんだよな。
難しい…
ま、C++ 使っとけと。

というわけで
どれも目くそ鼻くそ
趣味の問題っつーことだ。
お好きものをお試しあれ。

うちの会社の場合、
goto Kumiko; 　/* 40代上司には評価される */
goto Maki;　　/* 20代後輩には評価される */
こんな感じです。

Cだからあんな糞コードになるんであって、
C++でデストラクタを使えば無問題。

ここは汗もできない低能のすくつか

throw-catchのように使うのだけはありなんでない？

お前らの小細工などCPUに渡る頃には何の意味もない

C++でもすまぽつかわないとろくなことにならないけどな。

C++でfinally実装しなかった積極的な理由ってなにかあるの？

>>722
関数テーブルを通している時点でinlineになるわけない。

swtich対関数テーブルは、オレが試したところswitchの方が速い。


>>725
>op の値によっては jump を数十回繰り返す事を
>忘れてないか？

お前はswitchがif文の羅列になると思ってるのか？
まぁcaseの値によってはそうなる時はあるが、>>721は確実にそうならないケースだ。

with_goto
　　void* handle1=NULL;
　　void* handle2=NULL;
　　void* handle3=NULL;

　　handle=create(...);
　　if(handle==NULL) goto ERR_EXIT;
　　handle2=create2(handle, ...);
　　if(handle2==NULL) goto ERR_EXIT;
　　handle3=create3(handle2, ...);
　　if(handle3==NULL) goto ERR_EXIT;
　　v = getValue(handle3);
　　destory(handle3);
　　destory(handle2);
　　destory(handle);
　　return v;

ERR_EXIT:
　　if(handle==NULL){
　　　　エラー時処理
　　}else if(handle2==NULL){
　　　　エラー時処理
　　}else if(handle3==NULL){
　　　　エラー時処理
　　}
　　if(handle3) destory(handle3);
　　if(handle2) destory(handle2);
　　if(handle1) destory(handle);
　　return -1;

if(handle1) って何だよ...

とりあえず
もうとっくに21世紀だぞ
いったいどれほどそんなチャチなチューニングをする機会があるのだ？

チューニングっていうのか？

まぁ、いまどき速度とか読みやすさとか気にする奴がバカってことで。

昔も今も大事でしょ。

>>741
gotoを使わないためにどんな汚い重複したコードをも正当化してしまうアンチってバカだね。