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

why?

2げっとだぜ！

見難いから。
−−−−−−−−−−−−終了−−−−−−−−−−−−

switchと共にバンバン使え

>>4
すまん。switchでの利用方法を教えて。
俺、malloc(),Free(),エラー(フィルターのようなエラーチェック)以外では使ったことないんだけど。

>>5
分岐処理。

うちの後藤はVBerだから・・・

>>6
へ！？switchでのgoto分岐処理？どんなんよ？

breakの代わりにgotoする
毎回switchでテーブルjmpするよりも分岐予測が付く分、高速。

switch文なんてきょうびはやんねーんだよ。

これからの時代はStateパターンだ！

10 PRINT ﾞクソスレの悪寒！ﾞ:GOTO 10

爺さんが遺言でgotoには手を出すなと

必殺仕goto人

くだらなすぎてﾜﾗﾀ

goto師

goto 真希

仕gotoしろ、お前ら

くだらなすぎて笑えない

190 ﾓｼ A=1 ﾅﾗ ｲｹ 530

電車にGoto

だから！遅すぎたと言ってるんだ！

ある晴れた 昼さがり 市場へ続く道♪
荷馬車が goto goto 子牛を乗せてゆく♪

Cgoto

goto >>1

goto >>26

goto >>25

ごく稀にエラー処理で使うかな。
switchはtokenの解析でたまに使う。

くそう。ｽﾚﾀｲを見て喜んで書こうとしたことは、>>23が既に書いていた。

C#ってさあ、糞だよな。
Javaでgoto文を廃止したのにC#では復活させているんだぜ。
某runからやってきたレドモンドの某社のﾔｼとM$社員は、もうアホかと、

Javaでもgotoは予約語になってますが何か？
未練たらたらで復活させるかもしれませんが何か？

ttp://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#229308

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

すいません。英文字順で言う s - u の間のキーが壊れ、打鍵できないのです。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

goto文は無くならない。でもおれはほとんど使わない。（1行/20000行位かな）
この前エラー処理をgoto文でやれっていう顧客がいて、泣く泣く変更した哀しい記憶を思い出してしまったじゃないか。

>>30
まず復活はありあんな。
ラベル付きbreak, continue文もあればtry-catchステートメントもある。
もはやJavaにgoto文は不要。

>>30
Ｃでエラー制御するのにgoto文つかったけど、処理の制御が難しかったなぁ
Cにも continue文 や try-catch があれば楽なのにとｵﾓﾀ

func() {

リソース取得

リソース使用
-> goto error;

リソース使用
-> goto error;

リソース使用
-> goto error;

return 1;

error:
リソース開放他
return 0;
}

こんな使い方ばかりしてるけどよくない？

>>39
その形にはまる場合は良いが、下みたいな形を取りたいときがどうしたらよいかｺﾏﾀ

func() {
　　try {
　　　　・
　　　　・
　　　　・
　　　　try {
　　　　　　・
　　　　　　・
　　　　　　・
　　　　} catch {
　　　　　　・・・
　　　　}
　　} catch {
　　　　・・・
　　}
}

>>40に補足
例外処理の部分を関数化すれば良いと思ったが、「関数を分けるな！」との
お上からの命令があったもので。。。
いったいどうしろと。。。　ﾄﾎﾎ

>>40
実装に関わらない上の言うとおりに作って後悔しなかった試しがない
39はあくまでCのみで戻り値見なきゃなんない時の話です。

>>38
Cにもcontinueはある
それを知らないのはお前がアホだから

goto が最適であると判断される状況は、たまーにある。

goto は 逃げ

>>38は痛すぎ！

#define JUMP(p) goto p;

gotoは禁じ手

gotoよく使うよ！
経験則なんだけど、goto文使うと契約切られ難くなるんだよね。

Ｇｏｔｏ行為を行った場合は遊戯をお断りいたします。

ラベルを貼った時点で死刑

最初から作れるなら絶対使わないけど。
昔のソースのちょっとした改造で、元が・・だと、どうしても使うときがある。
いいんだよ、どうせ元が元なんだから！

setjmp とかは...

ロングジャーーーーーーンプ！！！！

longjmpも．．．

早退ジャンプ

>>43、>>46
今　VC++6.0　で確かめてみたらあった（ｗ
continue文って使えたんだ（ｗ

>>56
習慣少年ジャンプ

>>38が俺とかかわりのない場所で生きてる奴でありますように・・

>>59
そんな釣れない事言うなよぉ
unixで使えなかったんだよぉ

>>60
うそつくな、自分の無知を上塗りしてるだけだぞ。

オレは使うぞ＞goto

関数呼び出すよりもgotoの方が高速なので、
関数なんか作らずgotoを使ってください。

>>63
馬鹿丸出しだな。
そんな呼び出しなどせずに一本道をすべて記述しる。

>>64のプログラムはループしない模様

Cでは、try,catch無いので、例外的にゆるされる。

do{
　if(...)
　　break;
　...
　if(...)
　　break;
　...
}while(0);　

>>51
じゃあ君は switch 文を使わない主義か。

gotoは使いたくなるのが、自然な発想だよ。
というのはアセンブラ言語にはJMPなどがあって、それを使わないでプログラミングすることはできないからだ。
つまりCでgotoを使っていなくても、マシン語のレベルでは随所に使われているわけだ。

>>69
バカとハサミは使いようだが、バカにはハサミを使わせるな。

あとcontinueがないunixの詳細きぼん（ワラ

void main(){
goto kuroyagi;

kuroyagi: goto siroyagi;
siroyagi: goto kuroyagi;
}

gotoは使いたくなるのが、自然な発想だよ。
というのはアセンブラ言語にはJMPなどがあって、それを使わないでプログラミングすることはできないからだ。
つまりCでgotoを使っていなくても、マシン語のレベルでは随所に使われているわけだ。

そりゃそうだ
gotoを使いたくないのは人間の都合だから
つーかアホか?

まあ７２はＣ言語で書いてもマシン語に変換されて記述が無駄になると
思っているようだから、アセンブラなりバイナリダンプ入力なりで
開発をすればよろしい。

main と goto しかないソースなんて昔の制御系じゃ普通だろ。
LaticeC==マクロアセンブラだし。

うーん　なんかコンパイル出来なくなったんだけど　どうすりゃいい？
って相談された事あったな・・・・mainが数千行

Cでgotoを使わない理由？

○構造化プログラミングが提唱されたときに現役で、そのあとgotoの利用方法を考えなかったやつ。
○教科書にgotoレスって書いてるからと、なんも考えずにプログラマー名乗ってる馬鹿

上の２つのどれかに該当するやつは、使わない。

オレはこれだな。
○バカ新人がまねして使うとマズイから、極限まで使わない

gotoがあるなら使えばいいというのもわかるが、そうならないようなプログラミングを心がけるべきだし
動けばいいとか思ってるヤツは、手本になる立場になっていないだけだろう。

gotoの悪いところって
見通しが悪くるから保守しにくくなる
っていうところなんですか？

>>79
馬鹿が使いどころを考えずに使うと、あっちこっちに飛んでわけわからなくなるから。

>>79
人間はある程度パターン化して理解してるからね。

for ・ while ・　switch　使ってると　そこを考えなくてスラっとパターンとして読めるのに
それらで代替が利く所でgoto使われると、どういう処理かを考えなければいけない人が多いわけ。

ほら、 { 〜 } が begin 〜 end になっただけでダメになる人って多いじゃない？
それと同じで表面層に縛られてる人も多いんだよ。
たぶんキミは　begin 〜 end だろうと goto だろうと問題なく理解できる人なんだろうけどね。
そういう人もいることを考えてあげないとさ。

私は駄目人間ですか？

１．ルールを知っていて守る。
２．ルールを知っていて大抵、ルールを守る。
　　またルールを破るべき局面を知っている。
の二種の段階の違いかと。

>>1
だからそういう爺は後輩に譲れっての。

gotoは善とか悪とかで分けられるものではなくて
諸刃の剣である、といった感じのほうがしっくりくる

という感じに理解しましたがいいですか？

ちなみに私は化学分析屋です。
細かいツールなんかを作ったりする程度の趣味グラマです。

という事で、 goto 平気で使う人は　pascalやってみなさいというのが結論ですか？

関数内でgotoを３つ４つとあめあられのごとく
使うのは問題外だよな？
で、１つ２つを例外的につかっただけで
どうして見通しが悪くなるんだ？
そりゃ技量の問題だろ。というか技量もなにもgotoはキーワードなんだから
使い方知らんのはそれこそ問題外。

>>82
数じゃないだろとは思うよ。
状態遷移型のコードなら、gotoで遷移するのも普通だし、大量に使うし、使ってないと逆に読み難いし。

>>85
じゃ黙ってろよ。
趣味とプロじゃ違いすぎる。諸刃の刃のようなアルゴリズムを作るから
そういうことになる。

Cになじんだ後、MASMに戻ったら結局if, while, do-whileみたいな
ジャンプ命令の使い方しかしなくなり、最終的にはマクロを使うようになった。

>>89
まあまあ、そういわずに。
勉強の一環ということでおながいします。

gotoを理由を考えずに嫌がる奴
whileとforとdo-whileの使い分けをしないやつ。

両方とも大抵しょぼい。

>>39
でも指摘済みだけれど、
エラーを同じ関数内でリカバーする使い方は
非常にわかりやすくて良いと思う。

これをif文作ってその中でリカバー、returnなどされると
余計保守が困るというものだ。

下手にブラケットを使うよりも
gotoの定型を定めて使わせたほうがよっぽど建設的だと思うのだが
どうだろうか？

gotoを嫌うﾔｼは、「人間は必ず過ちをする」という自覚があるﾔｼと思われ。

初心者なため、
for(){for(){for(){for(){for(){for(){for(){for(){for(){for(){}}}}}}}}}}
から抜け出すにはついつい使ってしまう。
だってflagとか作って、一回条件に合わなかったら１代入して、
何回も
if(flag==1)break;
書くのめんどいしわかりにくい

多次元は　
for(x=0,y=0,z=0 ; z<サイズ ; inc(&x,&y,&z))
{

}
とか書くのはダメなのかな

>>95
とりあえずいえることは、おまえはプログラム組むな。

今さっきアルゴリズムの授業で「C言語にgoto命令はあるが使わないこと」って言ってた。
ジャクソン法とかいう話の延長だったかな。

>>95
そこに至る設計がそもそもマズい。やりなおし。

i: /*　処理 */ goto iiii:
ii: /*　処理 */ goto iiii:
iii: /*　処理 */ goto i:
iiii: /*　処理 */ goto iii:
iiiii: /*　処理 */ goto ii:

これを延々繰り返せば、自分以外はメンテ不能となり、開発費を
一人締めで丸儲け。

>>100
そんなの、ツール作って直しちゃうよ

そうか...ツールで直せないように作らないとだめか。
相当うまくやらないとダメだな。儲けを独り占めに出来ない...。

>>96
最小値は0固定として、
inc(&x, &y, &z, max_x, max_y, max_z)
くらいないと困らないか？

>>103
& を書いたけど実際はマクロで書くつもりでコードの少し上で書くから・・・・

>>100
それ、うまくできたとしても、自分もメンテ不能になる悪寒

>>100
こんなのはどうですか。
http://www.tw.ioccc.org/years.html#1987
の
hines.c

>>106
なぜ普通に
http://www.ioccc.org/years.html
を勧めない？

twって台湾だったっけ？

>>107
すまん。雑だった。

>>106-107
あー、こんなんあったねー。

なかなかすばらしいモノがあるね。

笑った笑った。モナーも作れそう。
http://www.ioccc.org/1985/lycklama.c

LSICじゃ動かんか・・・

for(){for(){for(){for(){for(){for(){for(){for(){for(){for(){}}}}}}}}}}

これは全部関数呼び出しにしろ！

>>85
そういう立場が一番プログラミングを楽しめるよね。

・構造化を心がけて、手続・関数化をまず行う。
・その手続内で、単純に if for whie switch が使える所は使う。
・それでもgotoが出て来たら、使ってよし（下手に再設計からやるとバグを入れてしまうからね）


ただし、
１、if for while swith が３重以上ネストするのは設計の失敗の可能性大
２、goto が出るのもやはり設計の失敗　

という事をふまえて、そうなったら次の設計では頑張るようにね

例外機構がない以上、gotoを使うのがもっともシンプルなコードであることも多いが。
例外よりは失敗しにくいのも確かだし。

>>49
> gotoよく使うよ！
> 経験則なんだけど、goto文使うと契約切られ難くなるんだよね。
>
そういうせこい技をつかうと相手も気づいて
C/C++/C#の使用を禁止しgoto文使用不可な
Java以外を使わせてくれなくなってしまう。

>>103
> >>96
> 最小値は0固定として、
> inc(&x, &y, &z, max_x, max_y, max_z)
> くらいないと困らないか？
>
汚い関数だ、コンストラクタでまとめれば引数の数が減るだろうに。

Cなのに

もしかして、ストラクチャーのことでは？

コンストラクタと言っているようだが

可読性が高ければgotoアリかと。
つーかデスマーチしたくなければ
読めるプログラム書け。

>>98 gotoを使わない理由はなんて言ってたの？

実際システム組んでて、goto使わなきゃ

みたいな場面になったら、設計見直すけどね。
多重ループを抜ける以外は。

まぁ、ありえないでしょ、と。

>>122
＞ 多重ループを抜ける以外は。
ネタだよね？

>>122
×多重ループ
○多重ネスト
では無いのですか。

またgotoは有限状態遷移を表現する場合にも使いますよ。

構造化プログラミングは万能かも知れないですが、
全ての場合において最適解であるかというと、私は懐疑的です。
これはネタではありません。

バカが多いから。

＞ またgotoは有限状態遷移を表現する場合にも使いますよ。
使えることは使えるが、状態を保持する変数を導入するほうが普通じゃないか？
＃変数使う余裕がないほどリソースが限られた環境は別として

多重ループから抜けるときは try catch だな。オレ様は。

>>127
ほう。try catchってどう実装すんの？（w

>>126
loopブロックの中に、状態を保持する変数によるswichブロックをいれる書き方ですね。
これは確かにロジックは構造化されていますね。
でもこれを読むのってgotoを使った書き方と同じ事だと思います。
残念ながらあなたの見解は私とは違うようです。
この件については「読んでいる方々の個々の判断に任せる」ことにしたいです。

同じなら構造化捨ててまでgoto使う価値は無い。

オレは状態遷移にgotoは使わないなぁ。
switchの前後で一つにまとまるから、状態によらない処理を入れるのが
楽なんだよね。

まぁパフォーマンスが欲しくなったら使うかもしれんけど。

>>131
手のみで書いてるの？　簡単なツール作ったりしない？

>>132
手のみですね。
趣味でコンパイラの勉強してるんで、それを別とすれば
ツールは使ったことないです。

サイトめぐりしてたら、こんなソース書いてるところに。
変数とか処理は省略。

switch( hogehoge )
{
case 0: hoge = 0;
　　　　　・
　　　　　・
goto label;
case 1: hoge = 1;
　　　　　・
　　　　　・
goto label;
・
　　　　・
　　　　・

　label:
hogehoge = hoge;
　　　　とかなんとか
break;
}

ラベルの飛び先を関数化すればいいんじゃないかなぁと思ったんだけど
なぜgotoを使うのか考えてみた。　なれなんだろうなぁという結論に。

移植なんかしないだろうけど、gotoがない言語もあることだし関数呼び出し
でまとめようぜと思った２００３年の秋。

ま、設計が良ければgoto使うことないね

try finally的後始末をする場合に遣うよ。
Cに備わっていない制御構文を実装するときに使うのはありだろ。

男ならば、分岐したり、繰り返したり、戻ったり、飛んだりはせぬもの。
上から下へと一直線に流れるプログラムこそ美しい。

goto使っても下へと一直線に流れるプログラム作れるYO

>>136
アセンブラコードを極力再現したコードを求めたら必須だが、
なくても作れるものをいちいち使うのは意味ない。

ﾀﾞｲｸｽﾄﾗたんがgoto（･Ａ･）ｲｸﾅｲ!!
って言った流れをＣも汲んでるから。

>>139
藻前様は関数内でmallocをしたことがないのか。
神と呼ばせてくれ。

>>141
なくても作れるのにいちいちmallocを使ってんのか？　ダメだのう。
ちなみにオレはmallocを関数内で呼ばなくてもする管理システムを構築したよ。
当然、グローバル変数ではない。Ｃ＋＋のクラスがもつ変数っぽい感じかな。
ターゲットによっちゃ重たいから親子関係が深すぎるとまずいが、プレスレ１
くらいでならなとか活用できた。

>>142
漏れにはｻﾊﾟｰﾘ見当もつかん。
どんなコードか晒してくれ。

gotoは普通に使うけどてめーらはたぶんエラーごとにfreeとか**close***書いてんだろ　バーカ
　

　

func () {
open***
malloc()
x = new ***

if(!処理A()) {
free(***)
close***();
delete x
return xxx

if(!処理B()) {
free(***)
close***();
delete x
return xxx

if(!処理C()) {
free(***)
close***();
delete x
return xxx


free(***)
close***();
delete x
return xxx
return ***
}

なんだか>>144は痛いコードを書いてる予感がします。

>>139
プロは、処理の見通しのよさやメンテのしやすさを念頭にコードを書くものだよ。

>>147
オレはプロになってもう６年以上だが。おまえごときにgotoを使うように
言われるほどヘタレじゃねーよ。
>>143
ここには書ききれねーよ。自分でＣ＋＋っぽいものを作ってみるか
Ｃ＋＋がクラスをどうやって実装してるか調べるかしてくれ。

むしろ中途半端に歳イッてるやつの方がクソなコード書くんだよなぁ
新しい情報に疎い頭持ってるヤツ

>>148
無駄なことやってるなぁ。

プレスレ１

ってなんでつか？

ホントのプロは創作の出来る奴の事さ。
創作が出来るというのは自分のスタイルを持つ事でもある。
お仕着せのルールを上から下命されてるようじゃまだまだだね。

っていうかgotoなんかつかわねぇよ亜穂

gotoなんかその存在すっかり忘れてたぜ
JAVAではたまに使いたくなるけどな

>>150
無駄？　Ｃ＋＋使えねー機種もあつかってんだよボケ。

>>154
嗚呼
墓場だねぇ〜〜〜

>>155
その程度も思いつかないおまえの知能がヤバイ。

↑2ちやんねるなんて、当然ｸｿばかり集まるわな

俺がＧｏｔｏを過去使ってしまったパターン

１、何度も出てるがエラー処理（例外処理のない言語で）
２、Ｗｉｚａｒｄ形式のプログラム作るとき（戻るって言うボタンの処理のため）

関数内でエラーが発生したときに関数の最後にエラー処理とかメモリ開放とか・・・goto使ってもいいじゃねーか
いろいろreturnごとに開放処理めんどくせーんだよ　

>>154
C++もどきなら、使わないほうがましじゃないか？

>>154
それがプレスレ1ですか？

>>154
まぁ大体何やってるか想像つくけど、カスっぺー奴だな

ハードウエア組込みCだと、goto文 普通に使う。
ランタイムの無い世界もある。

>>163
ハァ？
設計がクソだからだ、藻前

>>164
同意。

>>163
いつまで生きてるつもりだ？前時代グラマは

>>166
おまえが使っているPCのマザボに載っているBIOSは…

もうね、(ry

>>163
一切使うなとは言わないが、ループのためにgotoとラベル使うのはは
やめたほうがいいのではないか？

goto の使い方は、
K&R でも見るがよかろう。

goto使わないとコーディングできないってのは時代遅れなだけですよ。
まあ、それで食えるなら、好きなだけ使えばいいんじゃない？

>>169
K&R自体ﾃﾞﾑﾊﾟだし

>>171
ﾜﾛﾀ

まぁ一人で生きていくならgoto

//gotoless.c
#include "gotoless.h"

void function_hoge () {
　　better_return HOGE;
}

void function_other () {

:HOGE

}

//gotoless.h
#define better_return goto

>>174 setjumpとlongjump使え
ってこれはスレ違いだ。
これとgotoを同列に論じるな。

つうか関数内にしかGotoできないんじゃなかったっけ？

>>176
>>175

exceptionは、gotoにはあたらないのだろうか？

だとすると、Cでgotoつかってもいーじゃんよ。

活きているロジックの部分にgoto使うのはﾔﾒﾚつーだけの話よ、構造化でのgoto縛りは

>exceptionは、gotoにはあたらないのだろうか？
疑問文

>だとすると、
仮定

>Cでgotoつかってもいーじゃんよ。
確信

【総評】　わけわかりません。

int init()
{
　if(init1()){
　　if(init2()){
　　　if(init3()){
　　　　return SUCC;
　　　}
　　　exit2();
　　}
　　exit1();
　}
　return FAIL;
}

int init()
{
　if(!init1())
　　goto err1;
　if(!init2())
　　goto err2;
　if(!init3())
　　goto err3;
　return SUCC;

err3:
　exit2();
err2;
　exit1();
err1:
　return FAIL;
}

int init()
{
　if(!init1())
　　return FAIL;
　if(!init2()){
　　exit1();
　　return FAIL;
　}
　if(!init3()){
　　exit2();
　　exit1();
　　return FAIL;
　}
　return SUCC;
}

成功してなきゃ呼べない終了関数は作るな。

>>183
ｱﾎか・・・
正常に初期化されてない構造体だかメモリ領域のどこに
初期化済みかどうかを判定するフラグを持たせられるんだ？

全体が正常に初期化されていない構造体でも一つフラグを用意する事は出来るだろうし
正常に確保出来ないヒープならポインタがNULLかどうかをフラグ代わりにする事が普通だし

どうもアホです。終了関数を多重呼び出しできるようなシステムを
作ったこともないヤシにはアホにしか見えないようです。

やっぱそんな気を使うくらいならgotoを使った美しいプログラムを
書くように心がけるべきでしょうか？（笑）

>>179
修辞的疑問文はおやつにいれちゃダメなんですかー？

int init(){
　if(!init1())
　　goto err;
　if(!init2())
　　goto err;
　if(!init3())
　　goto err;

　return SUCC;

err:
　/* cleanup code */
　return ERR;
}

>>188
そこまでいったら話は早い

int init(){
if(!init1()) return ERR;
if(!init2()) return ERR;
if(!init3()) return ERR;
return SUCC;
}

main(){
if( init()==ERR )
{
cleanup();
exit( ERR );
}
/* apli code */
cleanup();
exit( SUCC );
}

>>189
初期化関数ぐらいならいいけれど。
関数内部で取得した一時リソースの解放は、その関数内部で行った方が安全だと思う。
メモリ、ハンドルリークとかはいやだからね。

goto 1;

goto 192

>>190
個人で開発している小さいプログラムなら、リソース開放を一箇所に
まとめるのは割と有効。

>>190
>>193
「リソースの開放を取得関数内でおこなうべき」って点は一致しているの？
ならば「エラー発生の都度リソース開放をおこなってreturnする方法」と
「エラー発生時はgotoを使用して関数内の一箇所でリソース開放をおこなう方法」のどちらが良いかという点が焦点なんだな。
前者を支持。
後者の「煩雑だという理由」は「リソース開放をマクロ化する」という方法で煩雑さを回避できる。

・関数ごとにマクロを用意する
・汎用のマクロで処理できる方法しか使わない
・ものすごいマクロを書いている

オブジェクト指向言語じゃないと苦労しますね（藁

>>196
>>183

窓閉じたら、ハッシュ表やキャッシュのエントリを消しまくって、
ファイルの変更を巻き戻したらファイルを閉じて、
テンポラリファイルを削除をしたあと、
通信相手に挨拶をして...
あとなにかあったかなぁ....

うちの会社と出身大学では、goto文禁止令が出ている。
そんでもってN88BASICの古いプログラムソースを見ると、GOTOが頻繁に出てきて
思いっきり萎えるんだ。

多用するのは当然問題だけど使い方によっては有益なんだから禁止する程でもないんだがなぁ。

例外が発生した訳でもなく多重ループから外へ抜け出る為だけに
Exception投げてるソースを見たことあるが、そっちの方が「なんで？」って感じだよ。
Exceptionの意味があまり分かっていないんじゃなかろうかと勘繰ってしまう。

>>200
gotoを使いたくないがためにそういう技を使うのは確かに邪道だな。
素直にgoto使ったほうが潔い。
Javaとかだとラベル付きbreakがあるそうだけど、これも本質はgoto
と変わらないのでは？goto否定派の人はコード上の善し悪しでなく、
なんとなく潔癖症的に嫌っている気がするな。

>200の場合はそういう多重ループを作らないといけない
事態に陥ったところがそもそも問題。

>>201
昔ながらの現場ではCOBOLの頃からの伝統にのっとり
コードの読み合わせ会が行われます。

そのような現場では、規約にgoto禁止とあると、gotoがあるだけで読み合わせ会が紛糾するので
皆さん規約にない方法で避ける事を考えなければならないわけです。

>>183
・終了関数にゴミを渡すとハングするので結局ハンドルなり構造体なりを前もって0fillする手間が増える。
・多くのライブラリリファレンスでは0を渡したときの挙動が明記されていないので呼び出しスタイルの統一を図れない。
・一般的なクラスのコンストラクタ・デストラクタの挙動と異なる。
というわけで183は糞。

　　　　　　　　　　　　　　 _,......,,,_
　　　　 　 　 　 　 　 ,､:'":::::::::::::::::｀`:...､
　　　　　　　　 　 ／::::::::::::::::::::::::::::::::::::::＼
　　　　　　　　　 i::::::::::::::::::::::::::::::::::::::::::::::::::ヽ
　　　 　 　 　 　 !::::::::::::::::::::::;‐､:::::::::＿::::::_::::';
　　　　　　　　　|::::::::::::::::::::::|　 ::￣　 　 　 ｀`!　　なんかもう必死でしょう
　　　　　　　　 r''ヾ'::::::::::／　　::　 　 　 　 　 |　　　goto回避潔癖症の人って...
　　　　　　　　 l r‐､＼::/　　_,,､ii_;;_､　　　 _,,,l､　　　　by 松本人志
　　　　　　　　 ヽヾ〈　　　 ::= -r:;;j_;､`/ :;'ィ;７
　　　　　　　 　 !:!_,､　　　　::　｀ ー　 : |: ｀´/
　　　　　　 　 ,./ヽ |　 ､_　　::　 ,: 'r' :i　|:　 /
　　　　　　 ,../　｀ヽ;_　　i　| '"､_:::__｀:'‐'.　/
　 　 　 　 /　｀`'ｰ ､_＼　　! `::｀￣''`ﾁ`ｼ
　　　　／ー ､_　　　　｀＼:､_　::　｀￣／
　　 ／　　　　　｀`ヽ､　　　ヽ｀'7‐--'゛
　 /　　　　　　　　　　｀ヽ、　`/

【Java/C/他】統合開発環境Eclipse M9
http://pc2.2ch.net/test/read.cgi/tech/1065974382/l50

脅迫ｷﾀ━━━━━━━(゜∀゜)━━━━━━━!!!!!

>>204
> ・終了関数にゴミを渡すとハングするので結局ハンドルなり構造体なりを
>　前もって0fillする手間が増える。
C++でもコンストラクタ初期化子は指定すべきです。
ましてコンストラクタのないCなら尚更でしょう。

> ・多くのライブラリリファレンスでは0を渡したときの挙動が明記されていないので
>　呼び出しスタイルの統一を図れない。
0 (-1でもいいんでしょうが) ならば呼ばなければいいんです。

> ・一般的なクラスのコンストラクタ・デストラクタの挙動と異なる。
意味が判りません。

結論: VBでも使ってれば?

>>202
アルゴリズムによっては多重ループが必要な場合は当然出てくる。(画像処理系等)
202は経験不足な割に態度がでかいのが問題。

>>208
おまえは画像処理の多重ループではgotoをずいぶん使っているようだが
そんなことしなくても問題ないニンゲンが沢山いることも知るべきだな。

アセンブラベースのゲーム移植のとき以外、gotoなんぞ使ったことねーぞ。

それは、設計の手抜きじゃないか？

>>209
もちろんgotoを使わずに書く事はできるけど、gotoを使わないプログラム
が本当にベターかどうかを議論している訳よ。

>>209
違う違う、画像処理に限らずアルゴリズムによっては多重ループもありえるって事だよ。
202はまるで多重ループになるプログラムはありえないみたいな書き方をしているから
複雑な数学を必要とする画像処理を例に挙げたまで。

俺だってgotoなんて殆ど使ったことねーよ。

・多重ループは構造化が十分でない事の証明だ
　　そこは別の関数にするべきだ。
　　負荷優先であっても
　　外側の関数呼出しは、内側がループである以上、殆ど問題にならない負荷だ。

・gotoは状態遷移型のアルゴリズムを実行遷移で実現する時、アルゴリズム通りに
　書く場合は許されると思う。

多重ループって何重以上のものを意識してるのかわからんけど、２重ループ
くらいだったら、ふつーに出てくるよね。３重もたまにはある。４重以上は
使った記憶ない。その２重・３重のループを抜け出すためにループ抜け出し
用のフラグを使ったり、例外発生させたり、あまり必然性ないのに内部の
ループを関数化するよりはgotoで脱出したほうがコードとしては素直だと
思うがどう？
そもそもgotoと、breakやcontinue(ラベル付も含む)って本質的になにか違う
んだったけ？飛び先が自由(無制限)か固定かだけの違いに思えるんだが。

>>213
別関数にすることをループが多重だからってことで決めるのは
好きじゃないなぁ。
ループが多重になっている箇所が、読みにくくなっているから、
別関数にする。多重ループでも読みやすければなにもしないぐらいに
して欲しいなぁ。

>>214
for (…) {　　　// A
　for (…) {　　// B
　　for (…) {　// C
　　　/* 何らかの処理 */
　　　goto EXIT;
　　}
　}
EXIT:
}
こういう構成の場合、BとCとが組で機能を実現していることが多く、
BとCと比べてAとBの関係は弱い。
BとCを関数化して、returnで処理を抜けるようにする。
こんな感じに内部のループを関数化することはよくやるけど。

飛び先を制限するだけでも、かなり追っかけやすくなると思う。

パフォーマンス云々を言い出すとアセンブラでやればいいとたどり着く。
そこを開発の安定という効率化を追及することでＣ言語やＣ＋＋がでてきたわけだ。
Ｃ言語でgotoあたりもうまく使わないとパフォーマンスが出ないハードでやってる
ヤツに使うなとは言わんが、Ｃ＋＋で作ったものでも十分に問題ない速度で動く環境
ならば、やはりgotoで抜けるのではなく関数化すべきだろう。

gotoに慣れ、関数化するほうが判りにくいというヤツもいるだろうが、物事の本質的
にそれはよろしくないですよ。関数化に慣れろ。

gotoを使うということはスパゲッティ化に拍車がかかるともいえる。
関数化することでそれぞれの関数がパッケージ化していくもんだが
それが面倒、慣れてないとなると容易にスパゲッティ、コピペに流れる。

当然、それしかなかったころからプログラムやってる連中はそんなことな
かったりするわけだが、問題はそんなことじゃない。

そういう連中がポインタもわからんようなやつ目の前にしてgotoは使ってもいい
と発言するのはマズイ。

内容的に関数にしたほうが自然な場合とそうでない場合があると思うんだな。
(1)複数の場所から呼び出す
(2)その部分を関数にしたほうがコードがわかりやすくなる
(3)処理が長い
どれかに該当すれば関数にする可能性が強いけど、どれにも該当しないような
場合、gotoを使いたくないがために無理に関数にするのはどうかと思う。

>>219
returnを使いたくないためにgotoを使うのはどうかと思う。

>>218
gotoなしでプログラムを書ける人達が、gotoを使用するべき局面が存在するか／存在するとしたらいかなるところなのか
を話しているんだ。
gotoは有害（である場合が多い）なのは事実だが、有害なのはgotoだけではない。
あなたのレスから判断すると、本当に有害だと思うのは
「ポインタもわからないやつらにプログラムを書かせなきゃならない」
という環境だ。

「多重ループから抜けるgotoぐらいで混乱するようなやつらに
プログラムを書かせなきゃならない」という環境については？

>>222「混乱する」なんてどこにも書いてないぞ。

結論：馬鹿はgoto禁止

包丁は人を傷つけるかもしれんが旨い料理も作れる。一概に凶器とは言えん。
などと言って、幼児に包丁持たすようなもんか。

>>225　巧いなあ

goto使用は免許制

>>227
それ良いね。goto免許制で議論はすべて解決するだろう。

>>226
基地外に刃物って言葉を知らないの？

なんか一連の流れを見てると、ここでいうまともなやつはバグの１つも
出さなくなって何年って感じな印象を受けるが。

そんなもんだろ。ここ数年バグなんて出したことがないな。何万行も
書いているんだがな。

>>231
１〜２年前はオレもそんな感じだったかな。３０前後でそうじゃなくなるよ。（笑）

そんなオレはgotoはあるから使えばいいやというのには激しく反対だ。

ループに突入するようなgotoはやめて欲しいが

多重ループ脱出とかは許容範囲では。
自分は、ここ数年使ってないが・・・

正直、アセンブリで書く時は、十分スパゲティ状態なので
Ｃのgotoなどカワイイもんで、気にも止めないんだが。

ただ個人的にはＣでgoto使う奴は腕が悪いと
教わった人にすりこまれた口なんで
脳みそが使いたがらないけどね。

最初にＣプログラムに出会った環境が
良くも悪くも影響しそうですね。

>>230
goto周りで面倒なバグ出したことは無いけどな。

意味もわからず後藤君はダサイと刷り込まれた人達が、
多重ループな処理を無理やりフラグを使って制御して
後藤君を使うよりもわけわからなくなる例を多々見てきた。
また、こういう人達はエラーが発生するとすぐにreturn
したがるのでメモリ開放漏れが多発する。

私しゃ、一定レベルのＰＧを集められなかった場合には、後藤君で
後処理に飛んで、そこで必ず資源開放を行うことをコーディング規則で
必須にしてる。



char *hoge_area;

hoge_area = NULL;

~~~~~~~~~~~~~
hoge_area = malloc(-----);

if( hogehoge()!=0 ) {
goto end_proc;
}

〜〜〜〜〜〜〜〜〜

end_proc:
if( hoge_area!=null ) {
free(hoge_area);
}
}

>>236
malloc,freeをフレームワーク側で面倒見るようにすれば、そんなものすら
必要なくなるよ。

途中で面倒くさくなって描画用ハンドルはそこに組み込めなかったけど、
開放忘れで苦労したことはほとんどないなぁ。

>>235
まあ、キミがプログラム初めて２〜３年の新人ならgoto使うのは反対とか
言わんがね。世の中のプログラマがキミよりできると君自身が信じている
なら、それは間違いだよ。

具体的に、どのタイミングでフレームワークに知らせるのか興味ある。

>>238
何のタイミングだ？
イクときか？

>>239
寝て良し。

立って良し、寝て良し。

>>232
意味がわからん。俺はむしろ20代後半からミスが激減しているのだが。

>>237
フレームワークでどのような処理するのか教えてケロ。

もしかして、プログラムや機能終了時に制御テーブル内のハンドルを
全部開放する方式？
それだと、メモリを喰いまくるような気がするのだが・・・
そもそもＣ言語で開発する意味ないような・・・

>242
30前後からまたバグ作り込む様になる、と言いたいのでわ？
# ま、歳だしな:-)

>>244
いや、もう30はとっくに過ぎてるんだけどね :-)

gotoなしでどうやってWizardライクなコード書くの?
いやもちろん書けるけどどうやってきれいに書く?

>>246
Wizardライクなコードってどんなの？

>>247
インストーラとかみたいに
「戻る」「次へ」
っていうボタンがおのおののダイアログにあって
順番に質問に答えていくパターンのやつ

>>248 そういうやつでgotoを使わないお手軽な裏技を紹介しよう。
それは、シナリオの部分をデータにしておいて、
それにしたがって遷移していく、という方法だ。

つまり、C言語のgotoを避けるために、
自前の「言語」とその「インタプリター」を作り、
その上でなんでも自由に使いまくる、
という万能goto回避ライブラリの簡略版を作るわけだ。

>>249
素直にgoto使った方が楽じゃないのか？

>>250 そうともいえる。9割冗談、1割本気。

goto云々とは別に、そういうやつはシナリオが変わることが多いと思うので、
ハードコーディングしないで、シナリオをファイルから読んだりしたほうが、
エンジニアリング上、楽な場合も多いんじゃない？

>>243
アプリ側では起動･実行･終了処理関数と、それら関数で使用する構造体のサイズを
フレームワークに登録するようにする。
フレームワークはメモリを確保した上で上記関数群を呼び出す。

アプリはフレームワークを介してアプリプログラムを自由に実行できるようにする。

これだけでmallocからは開放されるかと。メモリ確保できなかった場合は実行されない。
アプリ側でアプリプログラムを実行した場合もいわゆるハンドルを渡す形式にすれば
Ｃ＋＋で言うところのＮＵＬＬポインタでのメソッド呼び出しとかも回避できる。

まあ、Ｃ＋＋を使った方がスマートだけどね。Ｃでもこれくらい用意しておけば、しょーもない
開放忘れとか回避できるよ。

ちなみに３０前後でバグ〜うんぬんはオレの実例なだけで、年齢はもしかして
関係ないかもしれない。オレはもう疲れた。

>>252
そういうフレームワークを必要とようなレベルの人間が、Cでプログラム
組むってのも、何か違ってるような気もするけどな。

>>252
大きさが動的に変わる場合は？
終了関数はいつよばれるの？

>>252
うぅ〜ん。

どうもイメージがつかめないな。
メモリの確保の専用関数がいて、そいつが関数毎にハンドルを
テーブルに登録。
でもって、関数の抜け出す時に専用関数を呼ぶことによって
その登録したメモリを開放するって機構ですかね？

それだと、いまいち使えないような。

疑問その1）
メモリ確保を下位の関数がして上位関数が使用ってパターンは
多々あると思うのですが、それはどのように対応してますか？

疑問その2）
メモリ以外に共有メモリやセマフォやミューテックスちゃんとかの資源
開放はどうしてるのでせうか。

疑問その3）
そこまで簡略化できたとして、何故にＣを使うのか。
JAVAでいいんでないかい？
Ｃを使う理由は、そういう制御きっちりをしたいから
なんだけど・・・

多重ループを抜ける場合っていうけど
　for (…) {　　
　　for (…) {　
　　　if( 条件 )　　　goto EXIT;
　　}
　}
EXIT:

こういうコードって何で必要になるの？

１、全件検索
２、ループ中のエラー発見による作業中断

他にあるのかな？

１なら、検索処理として自立した関数・手続化するべきだ。
　そうすれば検索を2分検索などの手法で効率化するのが容易になる
　こういうコードが残っているのは、あきらかな構造化分析ミスだ。

２なら、構造化例外を持っているなら例外を、そうでないなら大域分岐を使うべきだ。
　CならLONGJUMPが使える。

>>254
動的変更はしないんじゃないの？

>>256

すまん。
構造化例外やＬＯＮＧＪＵＭＰってＡＮＳＩ規格になるのでしょうか・・・
そもそも、ＬＯＮＧＪＵＭＰって何のこと？？？
１６ビット時代のＬＯＮＧＪＵＭＰのこと？？？

longjmpはPOSIX準拠ではあるが、gotoよりも更に「最後の手段」では？

>>259
え？ Cなら普通でしょ？
回復不能エラーを発見したら後始末して大域脱出するもんじゃないの？

そこをフラグ作って分岐一杯入れるからバグを作り込んでしまうわけで

>>260
スタック巻きもどして途中の関数のデストラクタ呼んでくれるんだっけ？

>>259
gotoと大差ないでしょ。関数またいだジャンプもできるから、
使うときにはgotoと同様に注意が必要だろうけど。

>>261
C なんだからそもそもデストラクタは呼ばれないでしょう。
大域脱出を利用する場合は、
ヒープや後始末が必要なものは setjmpする時に用意した　ポインタに
リンクリスト式に処理をぶら下げてゆくのが常道だね。

そして、大域脱出時に、リンクリストを逆戻しに関数を呼び出してlongjmpすると

そして、処理の登録忘れが発生すると。

まぁ、なにはともあれ
「後藤君は使っちゃいけない！」
っと馬鹿の一つ覚えのように逝ってる奴は素人ってことだ。
ケースバイケースって言葉を知らないおこちゃま。

最終的には、バグのないコードを納品できれば言い訳で
使おうが使わまいが、ぶっちゃけどっちでもいい。

ただ、ループの中に飛び込む後藤君を書いてる新人が現れたら
お前は当分、後藤君禁止なと言いたい。

>>264
一つだけ開放する関数を用意しておけばそう忘れたりはしないよ。
・・・まあ自分で組む場合だけだけどね。

つまり
void func(void)
{
　リソース確保
　成功したら AddFreeFunc( 開放関数 , リソース);
でなければ　LONGJUMP<- 全部開放してlongjmp
　・・・　処理　・・・

FreeFunc(); <- 1個だけ開放する
}

てな調子にするわけ

>>248
そういうのは、状態を管理する変数を作り、
イベントが発生したときに、switchなりで状態により処理を変えると
いうように作っている。

>>256
> ２、ループ中のエラー発見による作業中断
(略)
> ２なら、構造化例外を持っているなら例外を、そうでないなら大域分岐を使うべきだ。
> 　CならLONGJUMPが使える。

breakに対しても同じ考え？

>>269
break も　検索か、エラー発見の場合だと思うけど、
c言語で1重ループの場合は、それは見れば判るという意味で許されると思うよ
pascalなら関数内関数が書けるから、検索なら関数内関数にするべきだと思うけどね。

>>255

キミは恵まれた環境にいるようだね。オレがそういうものを作ったのは
ターゲット環境にはアセンブラ／Ｃ／Ｃ＋＋しか選択肢がないからだよ。

Ｃでmallocを使うよりJAVAのように開放処理を自動化する方が安全だと
判ってもらえているようだけど、ようは安全だからそのようにしたわけ。
オレ自身はそういうもの作れる程度のレベルを持っていると思われるので
普通にmallocでもgotoでも使ってもいいとおもっているけど、他人はしれ
たものじゃないからな。　何度かしょーもないバグで時間取られたし。

gotoは使うなといってるんじゃない。「使ってもいい」と気軽に言うなと。
「ちゃんと設計を行い、gotoを使うことがもっとも効率がいい場合にのみ使ってもいい」
と毎回言って欲しい。じゃないとバカがすぐ意味不明な使い方するからな。

リソースの解放は、try-finally 使ったら？

>>271
なんか全く逆に思われてるようなのだが・・・
「Ｃでmallocを使うよりJAVAのように開放処理を自動化する方が安全だと
　判ってもらえているようだけど、ようは安全だからそのようにしたわけ。」

私はちょこざいな方法で自動化するぐらいなら、最初から実装
されてる環境を使ったほうがマシといってるだけで・・・
ＪＡＶＡの自動開放は、大雑把なシステムを作るのにはいいが
シビアなシステムにはクソだと思ってるわけで・・・
Ｃの環境に、ちょこざいな実装で自動化を持ち込んだら、
それこそＧＯＴＯ文よりも弊害が多いわけで・・・
後藤君は計算機システムでは当たり前の処理で、弊害を
教えればいいわけで。もし、後藤君がダメならCONTINUE君
も禁止するべきなわけで・・・
そもそも古いＢＡＳＩＣのプログラマからＣプログラマへの
転向者はもうほとんどいないわけで、心配しないでも
新しい人達は後藤君はほとんど使わないわけで・・・

continueが複数あるループの終了条件、
breakが複数あるループの直後の処理、
returnが複数あったりする関数のそれぞれの後処理などは
やはり、それなりの慣れと集中力が要求されるわけで・・・
できれば、避けるように指導しているわけで・・・

>>255
そういう方法だと関数を抜け出すときに、いかにきれいに専用関数へ処理を
流すかが問題となる気がするが。

つかswitchとfor/whileでbreakの意味が変わるという糞仕様を何とかしてクレオ

おんなじだろ
制御レペルの{}のそとにでる　という意味だろ

２５６の主張

　多重ループを抜ける場合とは
　　１、検索
　　２、エラー発見による作業中断

　のどちらかである。

これは真であるか？

gi

>>278
枝刈りのために抜けるとかは？

>>280
という事で
　多重ループを抜ける場合とは
　　１、検索+探索　
　　２、エラー発見による作業中断

でよろしいですか？

>>281
逆にエラーを発見しないときに中断というのもある。

細かいの挙げだすときりがないけど…

>>282
エラーを発見しない時に中断ってどういうふうに使うの？

>>283
通信とかで、こんな感じのことをする。

1) コマンドを送る
2) レスポンスを待つ
3) レスポンスがなければ、再度コマンドを送る
4) N回送っても、レスポンスがなければあきらめる

エラーを発見した(レスポンスがない)場合はループを抜けず
頭のコマンドを送るところに戻る。
エラーを発見しない場合は再送しないためループを抜ける。

あきらめた後、一定時間待ってから再度1)〜4)をやってみる
というのを簡単に組もうとすると多重ループを使う。
稀な話だし、他の組み方をすることも多いけど。

retryを例外処理にもつ言語だともっときれいに組めるんだと思う。
gotoで頭に戻してっていうのはあまりやりたくない。

こういう事？

for(j=0;j<REPTIME;j++){
　for(i=0;i<N;i++)
　{　 SendCmd(SendBuf);
　　 if( GetCmd(RecvBuf) ) {
　　　成功した場合
　　　return;
　　　}
　}
　Sleep(WaitTime);
};
この後、どうやっても動かない場合を書く

・・・・・・・
まあ、仕様書にこういうフローを書いてあったらその通り書くにはいいかもしれないね。

>>284
うん
そんな作り方はしない

さすがに多重ループのくだりは無理があるか…

if(条件A){
  for(i = 0; i < MAX; i++){
    if(条件B){
       /* C */
    }
  }
}
/* D */

の様な場合、CからDまで抜けたいときにはbreak使う？ goto使う？
おれは意気地なしなのでgoto使うけど。

breakに決まってるだろ。あほ。

本当の意気地なしはループ途中で抜ける度胸がなくて、最後まで廻してしまう。

いや、Dの処理をCの位置で行った上でリターンだね。

goto使う人ってmallocした後freeしなかったりvoid main()って書くってほんとですか？

>>291
素人

>>292
mallocした後freeしなかったり　→　逆
void main()　　　　　　　　　 →　全く問題なし

>>293
＞void main()　　　　　　　　　 →　全く問題なし

ほんとうに？
void main って書くと、OSに0を返すことを保証してるのか？

>>288 普通に構造化プログラミングでやっていると、
ループの後処理が追加される可能性が高くて、
Cから抜けたときも実行したいことが多いと思う。
そんな場合なら、break;
でも、条件Ａと同等の意味が条件Ｂにあるのなら、
ループの後処理はないと思うので「CからDまで抜けたいときには」
（ループに副作用がある場合、Cでキャンセル処理して）、
素直にgotoで抜ける。この場合、D以後でiは使わない。

と、オイラならする。

うぁ、今時不毛なこと言ってるね(ﾟДﾟ)
Cならgoto使いまくりじゃん。↓みたいに。

unsigned char *a=NULL,*b=NULL,*c=NULL;
if((a=malloc())==NULL) goto done;
if((b=malloc())==NULL) goto done;
if((c=malloc())==NULL) goto done;
hogehoge_operation;
done:
if(a) free(a);
if(b) free(b);
if(c) free(c);

C++やJavaならtry,catchやデストラクタ使えるけど、
Cじゃgoto使うのもしょうがないっしょ(;´Д`)

293はアホですか？

>>294
ＯＳにゼロを返さないといけないのでつか？
ＯＳが誤動作するのでつか？

void mainでreturn 0とならない最近のＣコンパイラをいえますか？

>>294
俺はむしろmainの後の()が空なのが嫌いだ。

>>298
よく覚えて無いけどVCはゴミを返してたと思う。
>ＯＳにゼロを返さないといけないのでつか？
は、確かにどうでもいい気がする。が、
>ＯＳが誤動作するのでつか？
そういう問題じゃなくて、このプロセスの戻り値を見る人が困るか
どうかが問題だと思う。なに返すかわかんないプロセスの戻り値
を見ることは無いから問題無いと思うけど。

goto使う人ってポインタ事前にNULLチェックしてからfreeに渡すってほんとですか？

>>298
> ＯＳが誤動作するのでつか？
OS ではなく、そのプロセスを作って waitpid() してる側が困るだけやね。make とかで
呼び出す時に、エラーと判定されて実行止まるとか。

アドレス０番地からデータを格納できますか？

環境による。

>>288
if(条件A){
for(i = 0; i < MAX; i++){
if(条件B){
/* C */
break;
}
}
if (i >= MAX)
break;
}
/* D */

>>296
typedef {ok ; unsigned char *a, *b, *c} hage;
hage foo = MyAlloc(void); <-メンバーを作成する
if (foo.ok)
{ 処理 ;
MyFree(&foo);
}

>>305
コンパイルとおらないんですが。

だいたい、void main()てANSI Cじゃないだろ。今時そんな方言
使ってる奴はアホだわな。

>>300
>>ＯＳにゼロを返さないといけないのでつか？
>は、確かにどうでもいい気がする。が、

よくねぇよ、アホ！
おまえはいいかもしれないが、そのアプリを使う奴がいいとは限らないんじゃ、ボケ！

>>299
>俺はむしろmainの後の()が空なのが嫌いだ。

おまえも逝ってよし。後ろの（）は空でも全く問題なし。

そして>>293は死ね。

>>309
そうかな？　必要ない事も多いだろう。

>>310
もう一度書こうか、お馬鹿さん。
おまえはいいかもしれないが、そのアプリを使う奴がいいとは限らないんじゃ、ボケ！

非ANSIならいらないけどな。

>311
そのアプリを使う人は仕様ぐらい知ってるだろう。

組込み "C"なら、 void main(void)のみ　はあるよ。
電源ONで飛び込んで来る。
ステートマシンを組むときにはgoto文も頻繁に使う。

>>301
そんなことする香具師は対症療法を治療だと思う愚者。
つまりポインタをNULLに初期化しておいて、mallocしないでfreeしてしまうという
しょうもないバグへの対処としか思えない。
原因はおそらくgotoの誤用だろうが。

>>301
そんなことする香具師は対症療法を治療だと思う愚者。
つまりポインタをNULLに初期化しておいて、mallocしないでfreeしてしまうという
しょうもないバグへの対処としか思えない。
原因はおそらくgotoの誤用だろうが。

DOSコマンドのみでそれなりのツール作ろうとすると
１ファイル内での分岐処理はgotoしかないので、それはそれでかっこいいぞ。
行ラベルを関数名だと思って眺めると、
引数や括弧がないので見た目すっきりしてかっこいい。

>>317
それなりのツールって何行ぐらい？

>>318
MSDE用の最低限のエンタープライズマネージャもどきで、
メインファイル１個と部品ファイル５個。
一番長いのは１１０行ぐらいで、行ラベルは１２個。

>>319 なるほどね。その程度の規模ならすっきり見えるだろうね。

>>314
そりゃコンパイラが文句言わないだけだろ。組み込みだろうが
なんだろうが、void main()なんて書いてる奴はアホ。

>>321
だから、そういうコンパイラも一部にはあるんですよ。
// そういったシステムでは、argc/argv 自体が無意味だったり。

ほんと、頭悪いですね。

>>322
mainをエントリポイントにする必要も無いけどな。

>>322
コンパイラが文句言わなければ何でもOKというあたりに、お前のとこの
職場のレベルが現れてるな(笑)。ま、お前みたいな低能が社員じゃ仕方
ないな。

>>323
必要はないけど、そうしておけば　後でスパゲッティを解きほぐす人の小さな助けにはなるね。
自前のCRTで立ち上げたらどこからスタートするかで何日も悩む事になるからさ。

>>321 >>324
こんな使い古された餌で　釣りですか？　しかも釣りざおも腐ってますよ。　ほらほら、みんな見て笑ってるじゃないですか。

>>326
ﾌﾟ。ANSI準拠のコードすら書けない低能PG必死だなｗ
ま、一番腐ってるのはお前の脳みそだけどな(爆笑)。

>>324
>コンパイラが文句言わなければ
むしろ argc/argv を指定するとエラーになる仕様。
莫迦だから想像つかない?

>>325
そりゃ、そんなものしか上げれないほうが悪い。
一人で趣味でやってるのなら別にかまわないが。

組み込みのコンパイラにANSI準拠を期待するのもどうかと。

あちゃあ、声かけたらなつかれちゃったよ。・・・トホホ・・・こんなのになつかれてもなあ・・・

>>329
そんなのしか上げられないって　どういう意味？

>>328
そんなマヌケな環境、想像出来る方がどうかしてるだろ。
まったく馬鹿はこれだからな。

>>331
はいはい。反論できないのなら出てこなくて良いですよ。
君の低能は確定してるんだからね(爆笑)。

>>328
そもそも、OSに戻り値を云々で void main と書くなアホ　っていう話だったのに、
組み込みの話で釣ろうとするから、粘着されてしまうわけだ。

組込み屋って、馬鹿ばっかりなの？

あーあー

>>335みたいな馬鹿が居ついちゃったよ

すぐ捨てるプログラムを書くときは、気分によって…
「あ〜、なんか、今日はreturn 0;とか書きたくねぇな〜〜〜。腕がだりーし。
　ま、イイか。void main() {っと。。。」

Cでgoto文を使う理由は？

C/C++もアセンブラに落とせばgotoしまくりコードと同等じゃないか。
そんなに神経質になるな。

>>314
void main()は別にかまわないけど
ステートマシンの場合は
ちゃんと状態遷移図と遷移表をつくって
goto使わないようにしろよ

>>337
しょぼ、return 0;なんて打つのに１秒もかからんだろ・・・

>>338
これまたゴミプログラムを作るとき…
「あ〜〜、このプログラムすぐ出来ると思ったのに意外と手間取っちゃったよ、めんどくせ〜〜
というか、適当に作ってたらループが7重くらいになってるんだが、最深部から一気に抜けないと
いけないことに今気づいたんだよ。 脱出フラグつけるのも( ﾟДﾟ)ﾏﾝﾄﾞｸｾｰし。。。
まぁ、goto loop_end;っと。んでloop_end:っと。おわりっ」

>>309
>>299=>>300だったりする。なんかすごい勢いで叩かれててﾄﾞｷﾄﾞｷするなあ。

>おまえはいいかもしれないが、そのアプリを使う奴がいいとは限らないんじゃ、ボケ！
>>299をちゃんと読んで。


>>俺はむしろmainの後の()が空なのが嫌いだ。

>おまえも逝ってよし。後ろの（）は空でも全く問題なし。
問題ないのは知ってる。引数無いときにvoidって書かないのが「嫌い」なだけ。
好き嫌いぐらい人の勝手だろ。

>>337
そんなあなたに、C++
int main() で、returnいらず。

>>339
天然のアホ？
それを突き詰めれば、CもC++も、ありとあらゆるものを否定しまくりじゃないか。

>343
> 問題ないのは知ってる。引数無いときにvoidって書かないのが「嫌い」なだけ。
あ、俺も。でもC++のデストラクタにはvoidを書かない主義。

>344
> int main() で、returnいらず。
warningがでるんで、やっぱりうっとうしい罠。

>>332
きっと CRTをカソードレイチューブの事だと思ったんだよ。
で、ここで切ったと。

自前のCRTで立ち ⇔上げたらどこからスタートするかで何日も悩む事になるからさ

あれ？　意味通らないや・・・・　不思議だね。

>>345
そこでwarning出すコンパイラが悪い。

警告なんてOFF

組込は別にして　一般アプリでも
mainで 必ず0を返す のと　不定を返すんじゃそんな差は無いと思ってたが
異常終了した時に自動的にエラーコードが入るという意味で差があるんだね。

>>349
OSによる。

>>350
異常終了は　 exit(コード)　か abort(void) で終わるって事だろうから　OSによるって事はないだろ

abort　は 確か exit(3) だったっけ？

>>345
>> int main() で、returnいらず。
>warningがでるんで、やっぱりうっとうしい罠。

本当に？　C++の正しい仕様なのにwarningでる？
そんなコンパイラは捨て。

>>352
VC++ 6 を捨てるのは惜しいなあ。

>>352
g++だと、-Wallつけてもwarningでないな。
というか、そのC++の仕様知らんかったし・・・はずかちっ

俺はむしろ引数無い時にvoidと書く奴が嫌いだ。

OSというとUNIXのことしか思い付かないやつや
WINDOWSのことしか考えられないやつらや
UNIXとWINDOWSのことだと思ってるやつらが
いっぱいいるのはどーしてなの

goto　放置;

>>353
惜しくない。
VC6は何かと古すぎ。
バージョンアップすべし。

>>356
自分の環境のことしか考えられない組込み屋がいっぱいいる
のと同じ理由だろ。

>>356
頭の悪そうな発言だな。
どこにそんなヤシがいるんだ？
少なくとも俺はお前よりは多くのOS上でプログラムを組んでる気がするぞ。

ま、ANSI Cという意味でvoid main()はありえないわけで。
UnixでもWindowsでも組込みでもな。それにしても356は馬鹿
丸出しだな。

いつから ANSI C の話になったんだ？

>>362
ANSI Cが出来た時から

これからはなかよく X-Windows でがんがろうぜ。

>361
それでは、うちで作ったOSは困る
32バイトのデータを返してもらわんと困るんじゃ

>>365
いずれにせよ、OSが面倒見るべき問題だな。

>>362
>>308

>>360
>多くのOS上で
OS がない環境では書いた事がないんですね?
なーんだ。

>>364
>X-Windows
釣られた方がいいかな?

>369
間違いは2箇所でいいかな。

OSが無い環境で書いてるのなら、void main()がおかしいことくらい
気づきそうなものだが。

>>368
だから誰もそんな事言ってないだろ。
早とちりばっかりだな。

>>371
なぜ？ 逆な気がするが。

>>373
非標準な環境では、標準を意識せざるを得ない。

ま、ANSI標準を踏まえた上で「俺はANSI以外も知ってるんだぜ」と言いたいだけ
なんだろうが、あまりにしつこいとウザイ。

判った判った。

これからは void main() ではなく vois Main()と書く事にするよ。　それで満足か？

>>374
> 非標準な環境では、標準を意識せざるを得ない。
ぜんぜん理由になってないのだが。

OSが無い環境でどこにリターンするのよ？

>>376
OSに値を返す環境があるということは知ってるわけですね(ｗ

>>377
常識だろ。

で、OSが無い環境でどこにリターンするのよ？
返す必要がないのだからvoidで問題ないだろ。

OSが無いということはmainが値を返す必要も無いので
普通はvoid main()がおかしいとは気づきませんね。

ANSIも知らない非常識人なわけないですよねぇ。

>>377 お前、煽りだけのクソレスすんなよ（藁

組み込みのコンパイラでは　レジスタ渡しかどうかで名前(リンカ名)が変わるのものがあるよね

レジスタ1個なら $func で 引数2個か引数voidだと _funcとか

組み込みではvoid mainは普通に使うよ。
この業界では常識。
それを知らないで標準とか抜かしている奴には
無知の無知という言葉を送ろう。

結局、「俺は普通人と違うんだぜ」と自慢したいだけか。
つまらん。

ANSI　金科玉条主義の人は Windows GUI アプリとはどうやって折り合いを付けてるの？

きっと自前のCRT作って int main(・・・を呼び出してるんだよ。

>>383
みんな知ってるよ。お前が無知。

>>387 ありがちな捨てゼリフだなｗ

そもそもmainの戻り値の意味も知らん奴がわんさかいるなかで、
組み込みはvoidだとか唐突に言われてもどうかと(w
それがどうしたんだよ、おまえら。

いつの間にvoid main()を論じるスレになったんだ？
Cでgotoスレじゃなかったのか？

>>390
ようするに>>292が悪いわけよ。

昔ムカついた奴の名前が後藤で、ステートメント書くとイライラするので使いません。

malloc/free問題があまり盛り上がっていないようだが。

#define JMP goto

もう　ＳＥ　ＰＧなんか　やってられね〜

まあ、組込みでも、極力gotoは使わないようにしているよ。
ただ、タイミングの関係や、定石として、gotoを使う処理は存在する。

囲碁屋だが、定石は変化するものだからな。
古い定石は良くないとされ、新しい定石が生まれていくし、
定石は背景となるルールによって変化する。

定跡は、最善でないかもしれないけれど、
実績があり、安定した結果を保障するものという意味合いが強いか

goto は廃れてはいない。　今VB開発だが
On Error Goto xx はGotoだ
これでエラー内容をログにも画面にも出してないヤツが居て、
処理も正常終了させてて、

「なんでここの値変わらないんだろう」という致命傷が残ってたりして・・(#ﾟДﾟ)＜○永！

なんか後半乱れてるな、書いてて思い出してイライラしたようだ

用は使い方
・飛び先が混乱しないようにすること
・飛び先を限定すること
・上に跳ばないこと
なんかかな

要するに、例外は使いこなせないと。

組込屋だろうがWindows屋だろうがUnix屋だろうが、void mainなんて
書いて平気な奴は馬鹿。OSがいようがいまいが関係ない。標準化された
C言語でint main以外はありえない。
「組込ではvoid mainは普通に使う」なんて言ってる奴は、まさに低能。
方言はどこまで行っても方言でしかない。だいたい組込でもint main
なところなんていっぱいあるし。組込屋って、やっぱり馬鹿が多いな。
そこでしか通用しない環境に埋没してるCOBOLerみたいだね。

>>400
ええと、 という事はあなたは WindowsGUI アプリを作る時にも >>386 ですか？　ご立派な人なんですね。

ご立派な人だから、また話題をスレ違いにひっぱろうというわけですね。

>>385
mainなんて使うか？

>>402
さあ？俺は使わないけど >>400は　int main 以外ありえないって言ってるぞ？

main使うのなら、int mainだろ。

で main を書かないのは ANSI の規約ではどうなのよ？

なんという小さいことを気にする人達であろか

ホントだね。
今時 C コンパイラが使われるのは　組み込みか UNIXかだ。
unixでは int を返せばいいし 組み込みでは　使う道具に応じて処理すればいいだけの事

>>393
確かにmalloc/free同期とれんﾔｼが後藤つかってたな。

検索ＫｅｙにＡとＢの値（例えば、A=身長、B=体重）を足して使えって、
言われたら本当に足し算しやがった。

ハッシュにしたつもりなんじゃないの？

俺の書いたﾌﾟﾛｸﾞﾗﾑにはいわゆる
”C言語”の始まるところ、すなわちmain関数に
相当する物が三つぐらいあるよ。

だから？

組み込みでも、エントリ名をmainじゃなくしてもいいんだけど
そうすると、判り難くなるでしょ？　アセンブラ見て判る人は意外に少ないからね。

だからわざわざ main にしてるんだよ。

つまり、その程度のものしか上げられないってことだ。

>>412
ソースの頭でインポートするシンボルを羅列する。
そこを見ただけで見当つくと思うけど。

頭ってどこだよ、関数単位でファイル分けするプロジェクトもあるぞ

CFAQも読んだことが無いお馬鹿さんばっかりですね


11.12:
main()をvoidとして宣言して「mainの戻り値がない」という目障りな メッセージを消すことができるか。

A:
できない。main()はintを戻り値とし、(適切な型の)0個か2個の引数 を持つと定義しなければならない。
exit()を呼んでもまだ警告が出る のであれば、冗長であるがreturn文を挿入するしかない
(あるいは使える環境にいるのであれば「ここには届かないよ:NOTREACHED」命令 を使う)。

References:
ANSI Sec. 2.1.2.2.1, Sec. F.5.1; ISO Sec. 5.1.2.2.1, Sec. G.5.1; H&S Sec. 20.1 p. 416; CT&P Sec. 3.10 pp. 50-51.
--------------------------------------------------------------------------------
11.14:
void main()と宣言してうまくいかないわけがないと思う。なぜなら main()から戻る代わりに、
exit()を呼んでいるから。だいたい今使っ ているO/Sはプログラムのexit値/戻り値を無視する。

A:
main()から戻ってくるかどうかは関係ないし、そのステータスを見る かどうかも関係ない。
問題はmain()の宣言がおかしいと、呼び出し側 (実行時のスタートアップのコード)が
main()を正しく呼び出すことす らできないかもしれないことにある。

君が使っているO/Sは終了時のステータスを無視して、void main()で もうまく動くかもしれない。
しかし、このやりかたは移植性が低いし、 正しくもない。

11.15:
僕がいつも使っている『ほんとおの馬鹿向けのC』には、いつもvoid main()と書いてる。

A:
たぶんその本の著者は自分も対象読者の一人に数えているのだろう。
不思議なことに、例題のコードでvoid main()と書いてる本は多い。 そういう本は間違っている。

--------------------------------------------------------------------------------
11.16:
exit(status)の値は、main()からの戻り値statusと本当に等しいのか。

A:
等しいときもあるし違うこともある。規格は等しいといってる。
ただ し、規格に従っていないいくつかの古いシステムの上では何かしら問 題がある。
また、mainにローカルなデータが、後片付けで必要な場合 はうまく動くことは期待できない。質問16.4を参照。
最後に、 main()を再帰的に起動する場合は上の二つは明らかに同じものではな い。)

References:
K&R2 Sec. 7.6 pp. 163-4; ANSI Sec. 2.1.2.2.3; ISO Sec. 5.1.2.2.3.

>>416-417
それを踏まえた上で楽しむスレですよ。

結論：void main()と書く奴は本当のお馬鹿。

>>419
はいはい、CRT, スタートアップもろくに知らない学生さんは
ム板に帰ってね。

で、mainなんか使う必要あるの？

Windowsと供に C->C++ に移行されてきた。
これからはUNIX/LINUX系でもC を使う場面は少なくなるだろう。

Cが残るのは　DLL/ドライバのように main を書かないシステムか、main
が帰らない組み込みのみ。

mainって必須なの？

>>423
どうしてもイヤなら他の名前使ってもいいよ。

さあ？
C の移植性は　関数単位・ファイル単位に確保すれば十分で、
アプリケーションレベルでそんなもの期待した事ないからなあ。

ファイル単位ってなんだよ。

>>421
void main()と書いてる馬鹿、必死だなｗ
C言語の話なのに、スタートアップコードの話に
すり替えようとすんなよ。お馬鹿。組込屋って、
ほんと421みたいな知障が多いな。COBOLerに
よく似てる(爆笑)。

組込屋がCOBOLerと似てるとは俺は思わないが、
C使いとCOBOLerには明らかな共通項があるよな。

今のやり方(他の人にとっては古臭いやり方)への固執。
新しいやり方の拒絶。

これってつまり、今のやり方に辿り着くのにそれなりに苦労しちゃって、
やっとある程度になったのにまた振り出しに戻るのが怖いだけでしょ？
達人プログラマと不思議の国のアリスでも読んで考えて欲しいよね。

話題がループしてるしｗ

main()の戻り値を習得するのにそんなに苦労するのか。
大変だな。

>>427
で？　ご自分は組込以外のC言語使いだとおっしゃりたいわけ？

具体的にC言語でどういうお仕事をなさってるんですか？
専門学校で教えてらっしゃる教師でしたら納得しますけどね。

はいはい、OS上でのアプリケーションを
書く場合はint main(char argc, char **argv)で宣言されているからそうしましょうねと。
mainを自分で宣言する場合は好きなようにしましょうねと。

こんな幼稚な話題バカらしいので終了。

だからさ、C言語で書く　OS上のアプリケーションて何なのさ？　CGI？

>>432
それはかなり不正確だと思うが。

いや、
int main(char argc, char *argv[])
だろ

確かに、 まだ void main() の方が救われるように思うな。

>>435
うまい！

>>436
C言語の知識もあやふやな奴である可能性高し。

>>435が正解。
初心者は、**argvなどと2重ポインタを見ただけで引いてしまい、難解な印象をもってしまうだろう。
それ以上読む気をなくしてしまい、たとえば、コードレビューや、ソフトウェア自身の機能追加時の
足手まといとなってしまう恐れがある。
*argv[]なら、char *型の配列であることが一目で分かるため、分かりやすい。
保守性という観点から見ても好ましいだろう。

みんなネタ引っ張るのが上手だねえ・・・・ そっちにふるか

>>433
君、ApacheとかC言語で書かれている事知らないの？
UNIX系統ではCのアプリ結構あると思うけど。

>>441
そのApache には void main(int argc, char *argv[]) なんてあるのを知ってての発言なんだよね？

>>435->>438

ダブルポインタが理解できない偽装C使い判明。

>>443
おいおい　ネタかと思ったらマジ？　バカでぇ

>>1-443 >>445-1000
goto hell;

grep 結果
apache_1.1.3/htdigest.c(111):　　void main(int argc, char *argv[])
apache_1.1.3/rotatelogs.c(19):　　void main(int argc,char **argv)

みなさん　ご苦労様です。　
具体的になればなるほど int main 派はボロを出してくれますな。

char argc がネタでなく書けるという事は、 >>443 が偽装C使いという事でファイナルアンサー。

typedef char* str;

str* argv

>>447
気づいたか。
でも char argc でもコンパイルではキャストされて通ってしまうんだよな。これが。
流石に void mainでは警告出すが。(VC)

char argcは、単純にint argcの間違いだと気づけ！
(中途半端なネタだったな。。。(´Д⊂)

そのネタ以前に知識の欠如があるような。。

まあだいたい　ANSIではＸＸ　なんていう奴は　たいてい底が浅い。
ANSI金科玉条主義のようでいて、ANSI 知らないとか、実際のアプリなんて書いた事あるのか？　レベルの奴ばかり。

それでいて、ANSI準拠じゃないとわめくだけ喚く。　今時 C 使うのなんて組み込みかドライバしかあるまいに。


じゃ C で何書いてるの？　と聞いたら ApacheがC言語で書かれていますよ・・・だとさ。
Apacheのソースなんて覗いた事もないのがミエミエ。　　
今からでもApacheのソース見てごらんよ。　ほら、ANSI準拠の int main はどこにあるんだ？

しまいには char agrc だとさ。　最初はお笑いネタかと思ったがマジですか。　まあそっちの方がオモシレぇけどな。

>>450
いやいや、ちゃんと >>443 を釣りあげましたよ。　なかなか上手いネタふりでした。

という事で学生さん達、　社会人になったら ANSIでは云々のウンチクはやめときましょうね。
１発でまわりに嫌われますよ。

今やってる人。まわりはハイハイとすましてくれるでしょうけど、目をよくみてみましょう。どんな目ですか？

まあやりたいなら２チャンネルでやりなさい。
でも、あんまりしつこいと　こうやってみんなにネタ引っ張られてハジかきますよ。

まあ、これをハジとも思わない人なら大物になれる素養がありますね。実社会でもどんどんやってください。

さて、自作自演劇場も終わったことだし元の話題に戻ろうか。

gotoは使うだろ！

>>456
どういう時に？

釣り上げたっっっっっっっっって・・・・
カジキマグロか

深いネストからの脱出のため…には最近あんまり使わないな。
あと例外の変わりに使うくらいかな？

>>450
int argc, char** argv
これを間違える時点で…

う、打ち間違いなんだよ！

ANSIに沿ってないプログラムを書くのはまあ個人の自由だ。移植性を失い、バグを誘発するだろうが。

そういう人はarray[i]=i++;と書くのもきっと気にしないのだろう。
自分の環境で、自分の思ったとおりに動いたらそれでいいんだろう。
そしてそれを注意してくれたやさしい人に向かって汚い言葉を浴びせ掛けるのだろう。

まあ、これをハジとも思わない人なら大物になれる素養がありますね。実社会でもどんどんやってください。

>>461
あんた、バグ出した時もそう言い訳してんのか？

ほう >>427 と >>454を比べて、どっちが汚い言葉だと？

どっちも汚いでしょ。

>>427は2chの煽りフォーマットに沿ったある意味2ch準拠の罵り。
>>454は嫌みったらしい2chではあまりない罵り。

なんで沢山あるレスの中からその2つのレスを取り出したのか？
自分に都合のいい情報操作の仕方の見本ですね。

>>462
何を言ってるの？　
ANSI の話で どうして array[i] = i++ なんてのが出てくるんだ？
その結果は ANSIで決まったとでも言いたいのか？

しかし配列に連番を入れたいのなら　普通 for(i=0 ; i<n ; i++) array[i] = i; でしょ。
それは ANSIに関係なく C なら普通にそう書くものだよ。

>>466
下は　 >>462が参照してるから出した
　上は void main を否定している一番近いものだから。
別に >>400 でもいいよ。

array[i] = i++ これがどうなるかはANSIで未定義だ。
同様にvoid mainでちゃんと動くかどうかはANSIで未定義だ。

>普通 for(i=0 ; i<n ; i++) array[i] = i; でしょ。
あんたにとって普通かどうか知らない。
それになそんなこといったらそもそもmain関数の戻り値は普通はintにするもんなんだよ。

もしarray[i] = i++と書いてる奴が同僚に居たらどうする？注意できないよな。
もし言うとしたらなんていって納得させる？
ANSIで未定義だから、という理由は使えないな。そう言ったら嫌われるんだろ？

そいつはこういうだろう。「俺の環境で動いてるんだから、いちいち文句いうな」ってな。
コンパイラ変えただけで発生する可能性のあるバグが潜んでしまうがそれでいいのか？

散々がいしゅつ>1-1000
C厨って頭悪いね

void mainは散々ダメだダメだいわれているのに、自分の環境で動くから正しいと言う奴がいるからね。しょうが無い。

>>469
そこに ANSIを出すから回りに嫌われるんだよ。

array[i]=i++;を注意するのや、　移植性の問題を出すのに　ANSI の話をする必要はない。
ANSIではなくて、　単に Cならそうじゃないでいいんだよ。

今となってはANSIはC の方言の一つにすぎない。
ANSIも C99という方言を生み出してるじゃないか。

どうでもいいよ。書きたいように書け。

>>471
アプリケーションというのは、その環境にあわせて作るものだよ。
特にmain の書かれたソースファイルは　その環境用に特別に作るのが C スタイルだよ。

あんたは単純にANSIという言葉の響きが嫌いという理由で反発するのか。

ふむ、そういう奴が多い職場があることは十分に考慮する必要を認識させてくれてありがとう。

>>475
そうだね。 ANSI とわざわざ付ける人のお話は尊大で退屈な事が多い。
だから嫌われる。十分考慮したほうがいいよ。

>>476
オマエも十分嫌われてそうな漢字なんだけど

もしかして、理想と現実のギャップに対する葛藤ってやつー？

カーーーーー、ペッ -------> 478 (ぴちゃ)

自分が伸びるチャンスを意味の無い反抗心で潰してもしょうがないのに。

>>479
よっぽど気に障ったの？
本当のことを言われると逆切れするのはよくないよ

>>469
>コンパイラ変えただけで発生する可能性のあるバグが潜んでしまうがそれでいいのか？
そのとおりだな。それを言った上で
だからちゃんと2ステートで書けと言う。

他者が見たときに身内に近い存在のヤツの技量が疑われるのは悲しいからな

↑ハェァ？

483は無かったことにしてください。

なぜコンパイラ変えただけでバグが出るんですか？
そんなコンパイラ使う奴が馬鹿でしょ。

>>485
C言語仕様の中には未定義動作とされているものもあって、
そこはコンパイラによってどういうコードを吐くか決めちゃっていい、
って部分があるんだよ。
なるべくそういう部分に引っかからないようにしようねってことだよ。
だからコンパイラがバカなわけじゃないんだ。

>>485
おっしゃりたい事を翻訳すると、
array[i]=i++; と書いたら警告出すようなコンパイラ使えよ！　って事ですか？

面白い意見ｷﾀーーーーー

とするとAのコンパイラからBのコンバイラに変えたときにバグが出たとき、
いったいドッチのコンパイラに非があることになるのだろう？

そこでANSI規格ですよ。

>>488 警告を出さなかった方という事で　は？

ヤバイ！「釣れた」発言がクル！↓

>>489
どっちの？

>>488
そういうソースをかく香具師に非がある

なぁ、後藤のはなしはどこに逝った？

>>293　が
>void main()　　　　　　　　　 →　全く問題なし

とか言い出すからこんなことになるんだ。
組み込みなど特殊な環境では問題ないとしよう。
だとしても、なんでこいつは特殊な環境の話に限定してんの？

そりゃ当然つっこむだろ。

なのにこいつはその後、組み込みではうんたらかんたら言い出してるし。
組み込みではうんたらかんたら言うのは嫌われる条件に入んないのか？
ANSIならうんたらかんたら言うのとナニが違うんだよ。

>>495
終わった話をまたムシ返すのも嫌われると思うが・・・・

まあ、それはいいとして、キミが相手してるのは一人じゃない。
少なくとも俺は >>293 ではない。
でも、void mainで 全く問題無いというのは同意するよ。

実際、 UNUXでもWinコンソールアプリでも、return を書かなくても exit を書けばいい。
そして、それらのコンパイラで void として問題が発生した経験が無いからね。
　え？もしかして俺の知らないコンパイラで動かない可能性がある？
それは、狼少年みたいなもんだ。現実に来たためしがない。
符号付整数が　２の補数じゃないマシンがありえるからというの同じ程度にね。

それよりは実際問題として、ポインタ幅やint 幅の差で苦労する方が余程大きいだろう。

組込みの話は、　今時 C コンパイラを仕事で使うのは組込み関係だけだ。
他に UNIX系が少しある程度。　だから、Ｃスレで組込みの話が出るのは　マ板なら当然だろう。

なんでC++を虫してんのかわかんね

>>496
あんな、俺も教えといたるけど、あんたが相手してるのは一人じゃない。
つーか、多分int main派の方が多いぞ。それが普通なんだから。

自分の環境で動くから問題ない、ですか　
もうダメな奴の典型ですね

>>498
はは、自分だって コンソールアプリ書く時は一応 int main だよ。
でも、 void main　や int WinMain は それより沢山書く機会があるというだけさ。

void mainと書く奴はそんなことも知らないのか、と危惧される可能性がある。大問題だろう。

>>416に
＞問題はmain()の宣言がおかしいと、呼び出し側 (実行時のスタートアップのコード)が
＞main()を正しく呼び出すことす らできないかもしれないことにある。
とかあるけど、本当にこういう例ってあるの？
もしくは、可能性として考えるとして、どういうケースが考えられるんだろう？

>>501
あなたは、Ｃのソース公開されたプログラムを覗いたりはしない？
void main がどれだけ多いかに驚いた経験はない？

>>503
ﾀﾞｶﾗﾅﾆ

>>496は、mainに限らず問題点となる可能性を指摘すると、
「これは、この環境ではうまく動くから大丈夫です。完璧に調べました」
と薀蓄をたれるタイプだな。

>>502
　たとえば、帰り値の型を　構造型にして呼び出した場合は問題が起きるだろう
　たとえば引数並びを>>43のように2間違った場合には問題が起きる事もあるだろう

　たとえば、レジスタを持たないマシンが存在するなら（全てメモリで計算する）
　帰り値 int の為にスタックを確保されていて、スタックミスマッチが起きる場合もあるだろうが
　それは実験室の中だけだろうね。

なるべく標準に準拠したコードを書くこと。
環境に依存したコードを書かないといけない場合もあるだろうが、それはなるべく最小限に抑えること。
これは意味不明なバグに遭遇しないための良い方針だ。

今時ANSI規格に沿って書けば、移植性が保証されると信じてる
原始人の集うスレはここですか。

>>505
いえいえ、 自分が書く時は コンソールアプリなら int main
もし void main と書いてあれば指摘されたら直しますよ。

でも人が void main とあっても 問題ないなら指摘しないですね。

標準に根を下ろし、ANSIと共に生きよう。
馬鹿な部下と共にデスマを越し、アホな顧客と共に仕様変更を歌おう。

どんなに恐ろしいコンパイラを使っても、沢山の可哀相な環境を操っても、
人は標準から離れて生きてはいけないのよ！！

>>508
もしかして、移植しなければどんなもの書いてもいいと思ってる？

>>510
だからどっちの　ANSI ？

>>508
ANSIから外れたコード書いてるよりマシってことに気付かないアホな来訪者がくるスレはここですか？

>>511
偉そうに。てめぇのぐちゃぐちゃコードは忘れて言いたいこといってんじゃねぇよ。

ところで、わざわざvoid mainにするメリットって何？

だからさ　main の部分を　別システムに移したら普通動かないでしょ？
引数３つのシステムとか　漢字コードの差とかさ、

普通、main はそういう　システムの差を吸収するためのコードを書くとこじゃないの？

>>515
オレに見返りを求めてもムダだぜってはっきり言えることかな。

>>515
メリットは 　コンソールアプリなら　exitで終了する事を明確にする事かな
組み込みなら、　CRT の関係と名前の変形のせいで vod main しか書けない場合もあるしね

>コンソールアプリなら　exitで終了する事を明確にする事かな

マジで明確になっているとおもっているのかよ。分かるかアホ。そんなことはコメント等で書くものだ

exitを書かなければ終了しないのか。

goto >1

>>520
サーバ系のコードなんかはそうだね。
main は無限ループで 終了は exitでとか

Apatchのソース見たけど
int main でも return 文が無かったり
void main だったり　けっこう節操ないね。

void main は、
(1) mainの中から抜けない（例えばコンシューマーゲーム）
(2) 抜けるときはexit等
(3) mainが戻り値を返しても環境が受け取らない
のどれかだろう。他にもあるかな？
ともかく、OS等が戻り値を受け取るのに返さないのは悪。
こういった条件を無視して、一律に語るのは厨房。

>>524
馬鹿か？OSが受け取ろうが受け取るまいが、void mainなんて
書いてる奴は一律低能なんだよ。

組み込みのmainと所謂ANSI　Cのmainは
名前は同じだけど、全然別物でしょ。

>>525
ﾌﾟｹﾞﾗ

>>523
うん。
そういったシステムで自分の乗る旅客機の制御がされてないことを
祈るばかりだな。Apache で人は死なんかもしれんが。

組み込みではWinMainのようにXXXMainと名付ければ解決

>>526
その根拠を述べよ。笑ってやるから。

ホスト付き(hosted)な環境ではmainの戻り値はintでないと正しくない。

ただし独り立ち(freestanding)な処理系ではそれは適用されない。

一緒くたに議論する馬鹿が多すぎ。もうやめろクソども。

うむ。なんか意固地になってる奴がいるな。

で、char argcの出番ですよ。
128個以上の引数は書いては行けないと言う諸刃の剣。
あまり素人にはお勧めできない。

6741・・・

蒸し返して申し訳ないが、
void main() を仕様外にしてしまったANSIの規格って、ちょっとセンスない。

main()を特別扱いしすぎでは？所詮関数なのだから、好きなように宣言すれば
よいでしょ？値を戻したくなければvoidにすればいいし。

OSから（組み込みでは電源ONで）最初にmain()が呼ばれるのは、言語仕様と
いうよりも、リンカによってあらかじめ用意してあるスタートアップがそれ
を呼ぶからで、それはリンカやOSの問題であって、コンパイラの立場では
そんなの知ったことかと。

long long main(int argc, char * argv[], char * * envp)

struct{
int a[10000];
} main(){

}

処理系がmainのプロトタイプを用意しているならそれに従う。
そうでなければANSIに従う。
そうでなければただのバカ。

さっき最近自分が書いたコードを眺めてみたが、2000行中gotoは一個も無かったなぁ。VC。
BASICでgoto 行番号なんて書いてたのは今思うと狂気の沙汰だと感じる。再利用性なんて考えたことも無かったあの頃。
今更goto使うところなんて無いんじゃない？エラー処理もtry〜catchやdo〜break〜while(false)で代用できるし。

>try〜catch
一応スレタイはCで、ということになってる

>do〜break〜while(false)
俺にしてみればこんな書き方をgotoの代わりに使う奴はクソ

>>539
むかし、構造化プログラム万歳な奴がプロジェクトリーダやってて、
do-break-while(false)を半強制してたのを思い出した。
本人は「本当は使ってはいけない」とか言ってたが、その下についた
奴らは無批判で受け入れてたな。

いいんじゃないの？
どんな書き方だろうが
プロジェクト全体で、同じスタイルが貫かれていれば読みやすいのは間違いない。

それを「いい書き方だ」と勘違いしてほかのプロジェクトでも使わなければよかったのに。

たしかに、
そのプロジェクトに入ったら、そのプロジェクトにあわせなくちゃね。

絶対的な基準があるわけじゃないのに　クソ　とかいうのは如何なものかと

C言語を名乗る以上int mainと書くのが当然。それ以外はCもどきの
方言にすぎない。方言をベースにC言語を語る組込系の使えない低能
PGは氏ね。

>>545
まだいるよ・・・・だからさ、キミはC言語で何作ってるのよ？

それ書いてくれないと可哀想な人にしか見えないぞ。

>>544
絶対的な基準でダメダメだろ。

>>547
で、絶対的な基準とは？

whileの意味をわかってない。

>>549
まあそれはご自分で勉強して下さい。　このスレはお勉強スレじゃないですから。

え？whileってgotoの代用のために作られたの？

>>549
プッ。

>>551
このスレではあなたがそれを言ったのは初めてのようですね。
どっかから電波受信しましたか？

XはYで代用出来る　と YはXの代用の為に作られたは同値ではありませんよ。

>>545
ANSI原理主義者ですか？
秋田ので詣でてこないでね

whileをgotoの代用で使うような奴は、
gotoをwhileの代用で使うのと同じくらい勘違いしていると思われ。

代用するくらいなら最初からgoto使ったほうがまし。
ラベル名を工夫すれば、なぜそれを使ったのかも明らかに出来る。
ゆえに、do 〜 break; 〜 while(false);はクソ

そんなのをプロジェクトのルールにするな。
他のプロジェクトで使おうとするバカが量産されて迷惑なんだよ！
使うならこのプロジェクトのローカルルールだということを徹底させろ！

>>556
それもひとつの見識でしょうね。

なぜ
switch(0){
default:
〜
break;
〜
}
ではいけないの？

>>557
じゃ、do 〜 break; 〜 while(false);の優位性を説明してくれ。
ひとつの、というくらいなら、もう一つ(以上)の見識があるんだろ？

>>558
それはどういう使い方するんですか？

>>559
　うーん。　ようするにスタイルの表現方法の問題だと思いますよ。
混在するのはダメですよ。でも、

関数開始
　{
　変数宣言
　do{
　　　 〜
　　途中で例外的処理があれば break
　　　 〜
　 　正常終了処理
　 return ;
　}while(false);
　 異常時終了処理
　 return ;
これを徹底すれば、それが一つのスタイルになり、判り難くはなりません。

確かに
関数開始
　{
　変数宣言
　　　 〜
　　途中で例外的処理があれば goto ABEND;
　　　 〜
　 　正常終了処理
　 return ;
ABEND:
　 異常時終了処理
　 return ;
でもいいですよ。　そう統一するなら　対応するだけです。

>>561
そこで、
「を、いきなりループに入るのか」
と思う人のことは想定外なのですね。

>>562
その問題は、
統一し、徹底すること。つまり　全ての関数の最初の do はループではないとルールを作る事で解決出来ます。

他に、#define で解決する方法もあります。　こちらの方がスマートですが、
制御文を#defineする事は嫌われる事も多いようです。

> 全ての関数の最初の do はループではないとルールを作る事で
かいけつしねーよばか

>>563
社内外含めて、何年も同じメンバーが担当しているプロジェクトでは適応できますね。
もっとも、わざわざ特別ルール作ってまで使うメリットはないと思いますが。

>>564
そうダダをこねないで馴れなさい。
その程度でダダこねてちゃ、明日からpascalを使えと言われたらどうするんですか？

>>563
最後の異常時終了処理がない関数でもdo〜whileで囲んでいるのでしょうか？

>>565
複数プロジェクトで違うルールがあっても対応出来ますよ。
関数は１画面に収まるよう短く作る事は普通のルールですから
そのプロジェクトで　do 〜　while(0) を見れば　そのプロジェクトはそのルールだと判断出来ます。

561の後者なら、なんの前提もルールも要らないわけだが、
それでも何か利点があるのか？

>>566
読むのに不必要な「慣れ」を要求されるようなコードを採用するのか。

>>569
利点？　利点で世の中回るなら苦労しませんよ。
gotoを書かないというルールが先にある場合には次善の策として十分有用なルールだという事です。

我侭が通るなら、 Windows開発は全てDelphiでやりたい。
でも、それはムリな話です。

>>571
gotoとdo-whileの比較をしているのに、
「goto禁止」という条件を課すのはいかがなものか。

つまり、goto禁止はクソを生む、ということでよろしいな？

>>572
　こういうのはスタイルを統一することが大事だから、
goto 派の主張には、　#define で定義する事を提案する事にしている。

#define で定義するのか、do while をそのまま使うのか、どちらかを選びなさい。と

プログラムの流れはブロックを飛び越せる goto でコントロールしてはいけない事も必要なら説明するよ。
でも、あなたのように熟練した人にはそんな説明は必要ないですよね？

ループでない流れを do while break でコントロールしてはいけないと思わないのかね？

>>575
goto派からは、たいてい、そういう反論があるんだよ。
だから、#define で見かけを変える事を提案するわけだ。

逆に do while 派が少数なら、それを錦の旗にして承服させるんだけどね。

>>576
ちなみに、どうdefineするのか？

>>577
それを goto 派の人に考えて作ってもらうのがうまくゆくコツだよ。

・・・正直 C /C++でチーム開発は疲れる　こういうレベルの打ち合わせでどれだけ時間を無駄にするか
・・・ああDelphiなら好きに作ってでいいのに・・・・

>>576
現場の問題は置いといて、
あんた個人は goto を do while break で全部置き換える事をクソだと思わんのかね？

goto禁止しなければ必要なし。

goto周りの議論ってどの案採用してもたいした違いは無いわりに議論の時間が長いんだよな。
その上主観と主観のぶつけ合いに終始して定量的なデータとか皆無。
会社でやられるとウザいから2ch内でうまくガス抜きしてくれればいいのだが。

>>579
　この２つは等価ななわけで、それにクソもなにもありません。

コンパイルされた結果は同じ。　表現の違いだけってのはお判りなんでしょ？
なら、考える時に、もうひとつ上の層を作って表現層の違いと捉えれてしまうだけでしょ？

>>582
がんばって、すべてのループをwhile()で書いてください。
それとも、#define BEGIN {とかするタイプ？

>>583
全てのループを while にするなんてのは簡単な事です。
それが仕様なら　いますぐ対応致しますよ。

begin と { の差程度の事で　ウロタえるつもりはありません。
何でも対応いたしますよ。

>>564
みたいな低脳野郎にレスする必要なし。

>>582
表現の仕方として、妥当かどうかが問題なのだが。
すべてをifとgotoで書き下したコードがまともだと思えるのか？

>>562
よくそんな小汚いコードを書く気になるなぁ。

>>577
#define TRYBEGIN do
#define TRYEND while (false)

とかやるのかな。

TRYBEGIN {
/* 処理 */
:
break; /* goto error */
:
return 0; /* 正常終了 */
} TRYEND;
/* エラー処理 */
return 1; /* 異常終了 */

とかやんのかな？

> この２つは等価
> 表現の違いだけ
さっきから do while break には、「統一、徹底、慣れ」などが必要だと言っといて、
そりゃないだろ。

ループするわけでもないのにいきなり無限ループに入るってのは、
何かキモいな。それなら素直にgoto使った方が良くねーか？

正直、そんなのは小さな問題です。
C++ でテンプレート禁止されようが、小さな問題です。
関数名に番号しか使っちゃいけないのも小さな問題です。

そういうのは、馴れりゃなんとでもなるんです！

決めてしまいましょう。

私たちの同僚に、　goto がどうしても好きな人がいます。
どうです皆さん。　彼にあわせる事にしましょう。

では、彼に、この件の　スタイルについてデザインを一任するという事で、決定でよろしいですね？

>>589
無限ループすると思っている人はこの議論に入る余地ないと思うのだが。

>>582
表記が違うだろ？
それがわかりやすさの違いにつながることがわからんのか？
do 〜 while(0)は、ループと間違えられる可能性がある。
一方gotoはその心配は無い。

>>591
誰が無限ループするなんて言ってるの？(見かけ上の)無限ループに
入るって話だろ。阿呆。

このスレッドってもしかして馬鹿が多くないか？int/void mainの
話題もそうだが、どうも低能が多いようだな。

>594
そういう煽りも含んで低能だな。
何しろ説明できていないんだから。

>>592
正直、私には同じですよ。　どっちでもいいです。

do while と goto の違いは、
gotoを使えば　　深いネストから ブロックを超えてgoto させる事が出来てしまう点です。
たとえば、ループをそこで作ってループ中から goto で抜ける事も出来てしまうわけです。
すると、初心者は簡単にこれを利用しようとします。
この場合、問題が起きないか良く観察しないといけなくなります。

まあ、それも別にそれに対する対処もなれているので、私はどちらでもいいです。

>>587
#defineすれば読みやすくなるのは分かるけど、
なぜわざわざdo 〜 whileをつかうの？

#define TRYBEGIN {
#deifne THROW goto ABEND
#define ERYEND } ABEND:

TRYBEGIN
printf("1\n");
THROW;
printf("2\n");
TRYEND;
printf("3\n");

でも問題ないよな？

つまり、do 〜 while(0)で問題ない理由に#defineすればいいというのは、理由になってないんだよ。
なぜなら、#defineするというのは、それ自体で独立した方法で、do 〜 whileとは異なる方法だから。

もう少し言うと、do 〜 while(0)を使うより
・#defineする(defineの仕方は問わない)
・gotoを使う
というほうがまし、というのが結論だな。

結局、do 〜 while(0)を使う理由は、「クソなコーディングルールに従わざるを得ない」以外の
理由は無いということだ。

ループ終了フラグ作るような初心者も、問題が起きないかよく観察しないといけないのは同じ。

>>593
おいおい　 do 〜 while(0)の　どこにが　(見かけ上の)無限ループなんだよ？

>>596
＞gotoを使えば　　深いネストから ブロックを超えてgoto させる事が出来てしまう点です。
＞たとえば、ループをそこで作ってループ中から goto で抜ける事も出来てしまうわけです。
＞すると、初心者は簡単にこれを利用しようとします。

はぁ？
だったら、コーディングルールで例外処理に限るとすればいいだろ？
例外処理にdo 〜 while(0)を使うとするよりよっぽどマシなルールだろ。
理由はすでに書いた。

>>597
それは最悪だ。
break と違って THROW はどこででも投げられる。
つまり、ネストしたブロック内からでもなげらる。

それが例外だろ？なんか勘違いしてねぇか？
それに、do 〜 while(0)つかうとしたら、普通のbreakと例外のbreakをどう区別つけるんだ？

>>591
whileについて単一的な使用方法しか想像できないだけだろ。

ネストしたブロックから一挙に抜ける方法は return / exit / abort /longjmp に限るべきだと思うけどね。

まぁ、do 〜 while(0)の利点を一つ挙げとくか。
・同じスコープ内で同じ表記で何度でも使える。
gotoだとラベル名を考えないといけないからな。

>>605
それも未構造化的だなあ

>>604
なぜ？
C++のtry節にcatchがある理由が想像できない？

>>602
区別がいらないのが do while の利点だろう

>>608
なぜそれが利点だと言い切れるんだ…

もうどうでもいいや。　おまえら会議だけしてろ。

俺がコード書いてくる。　おまえら俺のコードのデバッグでもすりゃいいさ。

文中に全角スペースがまざるレスは全部同一人物なのか？

漏れがgotoを使わない理由

こんな風な会議に付き合うことになってしまって作業効率がおちてしまうから。
以上

>>612
それは言えるｗ。コードレビューが長引いて帰れなくなるとか有りそうだしな。

>>613
いや、マジでそうですよ。正直面倒だもんね。

別に明確な理由があるわけではない。

単にガキくさい理由、
「みんな使わないから、使うと自分が馬鹿にされる。」
ということ。仲間外れにされたくないがために右倣えするガキ精神。

全員ハッキリした理由を出せていないのが証左である。
ということは、使うシチュエーションにも拠るがデメリットなどないということ
「使う場面を考えろ」というのは全ての関数に当てはまることだが、
なぜかGOTOだけは特別扱いなのがよくわからない。

…とあたりまえのことをいってみる。

このスレでダイクストラの著作にちゃんと目を通した奴の数→0

>>617
で、何？

判って使えばいいんだよ。だから特に制限しないよ。
　　　　↓
　　　1ヶ月後
　　　　↓
おまえらは・・・・これからはgotoは禁止ね。　例えロジックが長くなろうがgoto使うな！
　　　　↓
　　　1ヶ月後
　　　　↓
おまえら・・・これはネタか？・・・判った。俺が悪かった。
ここにスタイルシートを用意した。10ページある。
ここに該当するロジックはこのスタイルシートからコピペして使う事。
　　　　↓
　　　1ヶ月後
　　　　↓

do{
break;
}while(0);

↓

void foosub(){
return;
}

void foo(){
foosub();
}

つーか組み込みぐらいでしかCを使わないとかいってんのにムキになっちゃってまぁ・・・

>>621
「言ってんのに」ってコテハン持ってない香具師にいわれても何の説得力も無い

>>620
　うーん　そういう場合はこうかな

struct hogehoge{
int ErrCode;
　他に使用する
} foosub(){
struct hogehoge r;
　r.ErrCode=1;

とちゅでエラーならそのまま return r;

　r.ErrCode=0; /* 正常終了*/
　return r;
}

>>621
君のレベルが知れるよ。
そもそも君C言語使えるの？

関数内でgotoを使わずに自在にjumpする例。でも多重ループからの脱出には未対応。

void　hoge(void){
N1:　A処理;　goto N3:
N2:　B処理;　goto N4:
N3:　C処理;　goto N2:
N4:　D処理;
}

void　foo(void){
　　int　n=1;
　　while(n){
　　　　switch(n){
　　　　case　1:　A処理;　n=3;　break;
　　　　case　2:　B処理;　n=4;　break;
　　　　case　3:　C処理;　n=2;　break;
　　　　case　4:　D処理;　n=0;　break;
　　　　}
　　}
}

>>625
それに似たのを疑似マルチタスク的な処理とか
指定された通信シーケンスを実装するのに使う事があるね。

その場合は n を const にして、 break; を return にするんだけど

>>627
constにしてなんか意味あるの？

というか状態遷移する処理を実装するときの手法やね
やり方はいろいろあるけど

ごめん ×const ⇒　○static　だ

馬鹿ばっかり

>>1-632, >>634-1000
馬鹿

セーフ？

>>539です。
do-break-while(0)を言ったらこんなにスレが伸びると思わなかったよ。
C++使ってると、関数の途中で変数宣言＆初期化できないのは気持ち悪く感じるんだよね。まあ、俺がgoto使わない理由の一つです。

>>634
glibcのソースなんかはdo-break-while(0)のブロック内処理全てがマクロになってる
ヶ所があるな。

>>635
それはマクロで複文を展開してるからdo〜while(0)で囲ってるだけだろ

>>636
俺が言っているのはdo〜while(0)も含めてマクロになっているんだよ。

>>637
呆れた

>>637
おぬし、なかなかのアフォですな

>>637よ…おまえ…

>>638
え、なんで。
じゃあ恥を忍んでお聞きしますけどGCCのマクロの複文展開って
単に \付けるだけじゃダメなの？

>>641
いいんだけど、{ } のない if() とかにそのマクロを書くと
期待していない動作になりそうな気はしない？

#define MACRO b = a; \
a = c

if (....)
　　MACRO;

libc のそれは break してwhile(0) にジャンプしたいんじゃないと思うわけ。

>>634
＞C++使ってると、関数の途中で変数宣言＆初期化できないのは気持ち悪く感じるんだよね。
俺もそう思う。
まぁ、どうしてもってときは、ブロックで囲んで変数宣言するけどね。

>>642
まあ確かにdo〜while(0)の途中でgotoしたり、returnしているから、
理由はそうなんだろうね。
一つ勉強になったよ。

>>634
↓これと
>C++使ってると、関数の途中で変数宣言＆初期化できないのは気持ち悪く感じるんだよね。
↓これ
>まあ、俺がgoto使わない理由の一つです。

両者の関係がイマイチよくわからない。

>>643
まぁ、C99では関数の途中での変数宣言が可能になってるけどね。
個人的には、当面使うことは無いと思うけど。

>>644
なんかまだよく分かってないように見えるけど、複文を#defineするときに、
do〜while(0)でくくるのは、一般的によく知られたテクニックだよ。
gotoしたりbreakしたりreturnしたるする/しないかは関係なくね。
上のdo-break-while(0)問題とはあんまり関係ない。

無意味に多用すると怒られる類のテクニックだけど。

>>644
>>642の例でいくと
マクロを単純に { } で囲っただけでは
if(....)
　MACRO;
else {
　....
}
のところの else の手前に セミコロンが入って大変イタイことになるので
do〜while(0) が使われているんだよ。

libc のマクロにはたしか while(0) のうしろにセミコロンついていないでしょ。

gotoあるなら使えばいいだけのはなしで

ラベルが衝突しちゃう危険性を回避しているわけで

はいはい

いまやグローバル変数は全廃しようという時代だが、そういう話になると、
あるんだから使おう、とか、
組み込みでは、とか、
GNUのソースでも、とか、
まぁ、そんなくだらない議論になるんだろうな（いや、議論にすらなってないが）

というか、脳内で勝手な時代を作り出さないでほしい。いやマジで。

>>652
で、君業務で何作ってるの？

これはグローバル変数ではない。モジュールローカル変数だ！
そして、このモジュールは複数のファイルから構成されている！

でおｋ？

>>652
はいはい、じゃ期待に答えて

・組込では ヒープやスタックを制限されるから、グローバルか static 変数を使う
　変数は細かくメモリ配置させたりオーバラップさせる場合もあるから
　セクション管理も必要。
　コンパイラによってはセクション名を付けられるのがグローバル変数にしか出来ない場合もある。

・よって、組込とC++とで共用するようなモジュールでは構造体を使う事が多い。

構造体を使うというのは、
　変数１個２個なら関数内で確保するが、
　int buf[32] とかだとローカルに確保せず　構造体にして　ポインタを関数の引数として渡すという事。
　　組み込みではグローバルに。
　　アプリならローカルに確保してから呼び出すわけ。

まあ、グローバル変数は極力使わないのは当然だな。
使わなきゃならん場面もわかるが、そういう仕事は一人でやれる仕事だろうから
まあ、そういうのは好きにしたらええですよ。gotoも使いなはれ。

static にしてアクセサ経由でアクセスするわけにはいかんのか？

スレタイ「宗教戦争はここでやれ」にすればよかったな。

>>659
グローバルな関数も禁止です！

>>660
いや、やってるからもう目的も達成されてない？

　　li,,、　　　il,,,　　　　　 .,,i、　　llll　　　 llll　　　　
　　 ﾞﾞlli,,,　　 .ﾞﾞllii,,　　　llllllll　　 .llll　lllllllllllllllllll　　　
　　　　ﾟﾞlli,,、　　ﾞﾞllii,,　　 llll|　　 lll　　　　lll|　　　　
　　　 .,,,illﾞ°　 .,,,illﾞ°　 .llll　　 llll,　.,,,,ii,,,lll,、　　　
　　.,,illlﾞ゜　　.,,,illﾞ°　　　.llll　　 .llll、lllﾞ｀.,,lll!!lii、　　
..,,,,,lll,,,,,,,,,,,,,,,,lll,,,,,,,,,,,,,,,,,,,,,,,lll,,,,,,,,,,,llll,,,,lllllllllll,,,,,l,,,,,,　　
..lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll　　
..!!!!!!!!!!!!!!llllllllllll!!!!!!!!!!!!!!!!!lllllllllll!!!!!!!!!!!!!!!!!!!!!!!　　
　　　　　 llllllllllll′　　　　　lllllllllll　　　　　　　　　　
　　　　　,llllllllllll,,,,,,,,,,,,,,,,,,,,, .lllllllllll|.-、　　 .,,,、　　　
　　　　 .lllllllllllllllllllllllllllllllllll .lllllllllll|　　　,,iillllllii,,　　　
　　　　,illlllllllll!!!!!!!!!llllllllllll　lllllllllll　,,,,iillllllllllllllllli、　
　　　.,lllllllllllllﾞ　　　.llllllllllll　llllllllllliillllllllllllllll!!!ﾞ°　　
　　.,,illllllllllllllliii,,,　 ,llllllllllll　.lllllllllllllllllllll!!ﾞﾞ゜　　　　　
: ,,,illllllllllllllllllllllllllliiillllllllllll″ lllllllllll!!ﾞﾞ°　　　　　　　
..!llllllllllll!ﾞ゜ﾞﾞﾞ!lllllllllllllllllllllﾞ　　lllllllllll　　　　　　　　　　
　ﾞﾞ!!!!ﾞ°　　 ﾞﾞ!lllllllllllll!°　.lllllllllll　　　　　　　　　　
　 　 　 　 　 ,,illllllllllll!ﾞ　　　lllllllllll　　　　　 .,iiiiiiii,,,,　
　　　　　 .,,,illllllllllllll!°　　 .lllllllllll　　　　　 lllllllllllll｢
　　　 ,,,,iiilllllllllllllll!ﾞ゜　　　　.lllllllllll＿＿＿,,,illllllllllll″
　 .iiiillllllllllllllllll!!ﾞ’　　　　　 llllllllllllllllllllllllllllllllllllllllll!　
　 .ﾞ!lllllllllll!!!ﾞ°　　　　　　 .'ﾞ!!llllllllllllllllllllllllllllll!!!ﾞ°ね

　　li,,、　　　il,,,　　　　　 .,,i、　　llll　　　 llll　　　　
　　 ﾞﾞlli,,,　　 .ﾞﾞllii,,　　　llllllll　　 .llll　lllllllllllllllllll　　　
　　　　ﾟﾞlli,,、　　ﾞﾞllii,,　　 llll|　　 lll　　　　lll|　　　　
　　　 .,,,illﾞ°　 .,,,illﾞ°　 .llll　　 llll,　.,,,,ii,,,lll,、　　　
　　.,,illlﾞ゜　　.,,,illﾞ°　　　.llll　　 .llll、lllﾞ｀.,,lll!!lii、　　
..,,,,,lll,,,,,,,,,,,,,,,,lll,,,,,,,,,,,,,,,,,,,,,,,lll,,,,,,,,,,,llll,,,,lllllllllll,,,,,l,,,,,,　　
..lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll　　
..!!!!!!!!!!!!!!llllllllllll!!!!!!!!!!!!!!!!!lllllllllll!!!!!!!!!!!!!!!!!!!!!!!　　
　　　　　 llllllllllll′　　　　　lllllllllll　　　　　　　　　　
　　　　　,llllllllllll,,,,,,,,,,,,,,,,,,,,, .lllllllllll|.-、　　 .,,,、　　　
　　　　 .lllllllllllllllllllllllllllllllllll .lllllllllll|　　　,,iillllllii,,　　　
　　　　,illlllllllll!!!!!!!!!llllllllllll　lllllllllll　,,,,iillllllllllllllllli、　
　　　.,lllllllllllllﾞ　　　.llllllllllll　llllllllllliillllllllllllllll!!!ﾞ°　　
　　.,,illllllllllllllliii,,,　 ,llllllllllll　.lllllllllllllllllllll!!ﾞﾞ゜　　　　　
: ,,,illllllllllllllllllllllllllliiillllllllllll″ lllllllllll!!ﾞﾞ°　　　　　　　
..!llllllllllll!ﾞ゜ﾞﾞﾞ!lllllllllllllllllllllﾞ　　lllllllllll　　　　　　　　　　
　ﾞﾞ!!!!ﾞ°　　 ﾞﾞ!lllllllllllll!°　.lllllllllll　　　　　　　　　　
　 　 　 　 　 ,,illllllllllll!ﾞ　　　lllllllllll　　　　　 .,iiiiiiii,,,,　
　　　　　 .,,,illllllllllllll!°　　 .lllllllllll　　　　　 lllllllllllll｢
　　　 ,,,,iiilllllllllllllll!ﾞ゜　　　　.lllllllllll＿＿＿,,,illllllllllll″
　 .iiiillllllllllllllllll!!ﾞ’　　　　　 llllllllllllllllllllllllllllllllllllllllll!　
　 .ﾞ!lllllllllll!!!ﾞ°　　　　　　 .'ﾞ!!llllllllllllllllllllllllllllll!!!ﾞ°霊の騎士！！

ええと、このスレで荒らしたくなるほど叩かれたのって誰？

・goto絶対禁止
・void main()全然OK
・do 〜 break 〜 while(0)は有用
とか主張してた奴だろ。

>>666
見事に釣られましたね。

俺は別に荒らしをしようと思ったわけじゃなくて>>663のAAを見て頭に浮かんだネタを素直にレスしただけですよ。

たった2レスで嵐と判断するような早漏はイラネ

・do 〜 break 〜 while(0)は有用

これはしかたなく使ってる例があるっつってんだろ。スレ読んでんのか？
その程度の過去ログチェックもできねーやつが、gotoを使うなと。
ぜってーバグだらけで、ロクでもないことになるからな！

と、私は言いたい。

>>670
釣られてる？

＞絶対的な基準があるわけじゃないのに　クソ　とかいうのは如何なものかと
クソじゃないと思ってる奴もいるわけだ。

>>671
goto使わなきゃプログラム作れないヤシもいるってことだな？
そんなやつは氏ね！

どこからそんなことが読み取れるのかと…

goto THE_REQUIEM_TO_THE_WORLD;

goto hell;

hell:
system("/bin/rm -rf ~");

THE_REQUIEM_TO_THE_WORLD:
　　resume();

おみゃ〜らよ、gotoはあるが、comefromがないのは何故よ？

>>678　そんなbitに大昔に載った腐った冗談を書いて楽しいのか？

678はｼﾞｼﾞｲ

どういう冗談なのかわからないので必死に考えてみたんですが…

「イクぅ〜」はあるのに「Oh It's coming!」がないのは何故か？

違うよなぁ。別に面白くないし。

comefromはラベルなんです、とﾏｼﾞﾚｽ

10 GOTO 10

こんなことを書く馬鹿がいるからです。

もし手元にLinuxがあるんだったら、
syslog と acl系のソースコードを読むと、
goto の弊害がよくわかる。

whileの中に goto で飛び込むソースと、
巨大なswitch文を goto で飛び回るソースがどんなに読みづらいことか

>>684
そんなもんは議論の対象外だ

まぁコードを一行一行吟味してコードを書く余裕がない場合、
盲目的にgoto使わないってルールを採用している方が
結果的に読みやすいコードになる確率は高そうだな。

>>686
まあ規約って馬鹿に合わせざるをえないからね。
でもgotoで上に戻るの禁止ぐらいの規約で十分だと思う。

>>686
読んで思った。
VBのように言語自体が腐ってるとgotoでもいいから吟味して使わないと
体裁がひどいことになる言語が在ると思うとCってまだまだステキに思える。

激しくスレ違いですまん。

>>688
ﾊｧ？

Cの構文とVBの構文に差があるとは思えぬが。

「BASIC」という言葉に惑わされてるんでしょう。
言葉のイメージに惑わされるのは初心者がよくかかる罠

gotoで飛び回るコードって、なんかすてき。
我々はいつのまに翼を失ってしまったのだろうか。
ティンカーベルはもはや我々の前に現れてはくれないのか。

>>691
>ティンカーベルはもはや我々の前に現れてはくれないのか。

下手に現れたら問答無用で撃墜されるのがわかっているから来ないんじゃないか？

どうやら結論は出たようだな。

結論：
gotoは、プログラムの生産性、保守性を極限まで落とし
使えばたちどころにプロジェクトを崩壊まで追い込んでしまう。
よって、どんな場合でもgotoの使用は禁止。
ついでにグローバル変数もどんな場合であっても使用禁止。
open()したら対になるclose()を必ず書くこと。
malloc()したら対になるfree()を必ず書くこと。
void main()はたとえ組み込み系独自処理系であっても使用禁止。

>>694
センス０

>>694
「莫迦の雇用禁止」なら一行で済む。

goto使ったほうがいい場合あるじゃん
と言う奴は根本から出来が悪いだけだ

>697
おまえのほうが出来悪そうだけどなｗ

どうも「一つの方法を覚えてうまくいくと、その方法しか認めなくなる人」や「有限状態遷移を知らない人」がいるような気がするんで、先に言った有限状態遷移のサンプルコードを書いてみます。
動作環境が手元に無いので試験していません。バグがあっても勘弁。

「ｃのソースコードからコメントを除去する」というコード片です。
仕様定義やスタイルに異論がある方もいるでしょうが、それがメインテーマではないので突っ込まないで下さいね。

#define SLASH '/'
#define ASTER '*'

not_incomment:
c = getchar();
if ( c == EOF ) return;
if ( c == SLASH ) goto find_slash;
putchar( c );
goto not_incomment;
find_slash:
c = getchar();
if ( c == ASTER ) goto incomment;
putchar( SLASH );
putchar( c );
goto not_incomment;
incomment:
c = getchar();
if ( c == ASTER ) goto find_aster;
goto incomment;
find_aster:
c = getchar();
if ( c == SLASH ) goto not_incomment;
goto incomment;

(続き)これを構造化すると以下のようになりますか。

enum { not_incomment, find_slash, incomment, find_aster } state;
for (state = not_incomment;;){
c = getchar();
switch ( state ){
not_incomment:
if ( c == EOF ) return;
if ( c == SLASH )
state = find_slash;
else
putchar( c );
break;
find_slash:
if ( c == ASTER )
state = incomment;
else {
putchar( SLASH );
putchar( c );
}
break;
incomment:
if ( c == ASTER ) state = find_aster;
break;
find_aster:
if ( c == SLASH ) state = not_incomment;
break;
}
}

前者と後者はどちらがbetterかという話ですが、私は前者がbetterであると判断します。書き易さも読み易さも保守性も断然、前者が優れています。ですが、後者の方がbetterであると判断する方もいてもおかしくはないです。と、それだけのことですが。

おおおおおおおおおおおおおおおおおおおおおおおおおおおおお



恐ろしいほどのクソコードだな……ｷｾﾞﾂｼｿｳ

701はクソと言うが、確かに元124の言わんとしていることはわかる。
ただし、699のようなケースはまれであることが理解できずに、
他の構造化のほうが有用な局面でgotoを使っちまうことが多いんだな。
gotoの使用を認めると。要は濫用されるってわけで、それが困る。
もっと簡単に言えば、「基地害に刃物」だ。

それに、699は700よりもコンパクトで高速でエレガントだろうが、
そこまでのコードを書かなければならんような状況そのものが
もはやまれだろうと思うな。
699と700を天秤にかける前にやることがあるだろ？ってこった。

>>702 ありがとう。すばらしいレスです。

gotoの使い方が解らないのはまずいでしょうか？
ラベル貼ってソコへ飛ぶという事まではわかりますが、どうやればうまくgotoが使えるか解らないんですけど＾＾；
やっぱまずいっすか！？＞＜；

>124
せめて使えるソースで例を出してくれんと俺も>701の状態になってしまう

>>702
俺ねぇ、3000行くらいある関数(一つの関数)で>>699みたいなことやられたことある。
あのコードの保守は死んだよ…マジで。

というか、大域脱出以外で見たことあるgotoってそんなんばっかり。
関数は長くて100行くらいとかいうことを言う人も多いけど、>>699は
そういうのと矛盾しないのかなぁと。

>>700
俺だとこんな感じに書くかも

c = getchar();
while(c != EOF){
c2 = getchar();
if(state != comment){
if(c == SLASH && c2 == ASTER){
state = comment;
c = getchar();
}else{
putchar(c);
c = c2;
}
}else{
if(c == ASTER && c2 == SLASH){
state = not_comment;
c = getchar();
}
}
}

ダメ？

>700はもう一度基礎からやり直した方が良いということで

>>700
EOFのチェックはこうしないと、incommentのところで
無限ループになる可能性がある。

for (state = not_incomment;;){
  c = getchar();
  if ( c == EOF ) return;
  switch ( state ){
  case not_incomment:

これを>>699に適用すると…

>>705 使えるソースでなくてゴメン

>>706
単なるバイト列（文字列）を扱うので>>699はあんなに単純になっています。
3000行にもなるなら当然もっと工夫が必要でしょう。私もそんなのは書きません。
>>699は「有限状態遷移を表現するのにgotoを使う例」として挙げたものですから。

>>709
はい。コメントが「*/」で閉じていないと正しく動きません。仕様定義上のバグです。

>>707 ダメだとは思いませんよ。
#コメント状態から抜けるとき、正しく判定していないように思いますが。

>>710
仕様定義上のバグがどうとかではなく保守性の話。

>>709を>>699に適用すると
if ( c == EOF ) return;
を三ヶ所に追加しなければならない。

Stateパターン使えよって言っちゃ駄目なんですか？

>>124　699,700

状態遷移を扱うのなら
状態遷移図とか遷移表を作るだろ
自然とgotoのないプログラムになるんだよ

状態遷移を扱う場合は
プログラムを読んで何をしたいのか理解するのは難しいだよ
プログラムより仕様書とかのほうがたいせつなんだよ

みなさん124をいじめないでください
かれはわかっててやってるんですよ きっと

状態繊維でマトリックスを作るのはカス
制御屋のソース見せてもらえ

>>716
でgotoばかりで読めない、と。

>>716
見せてくれ！

>>716
ﾏﾑｺうｐｷﾎﾞﾝ

>>716
やらないか？

いや、ﾏｼﾞで！

>>699
getchar() を fgetc() に仕様変更しなくてはいけない場合、
そのコードでは３箇所書き換えなくてはいけないけど、
それでも「これは保守性が優れている」と言い張るつもりなの？

>722
ごめん、４箇所か・・・

putcharをfprintfに変えないといけない場合も、2箇所も変えないといけないな！

>>722-724
うーん。基本的に「言い張る」つもりはありません。「私はこう思う」というレベルの話です。
保守性に限って言えば「修正個所数の多寡」と「読みやすさ」のどちらを重視するべきかということですね。
私は後者を重視し>>699に軍配を上げているだけです。当然、前者を重視すれば>>699に軍配は上がりません。
どちらを重視すべきかはいろいろな要素があり、一概には言えません。

>>702の言う通り、gotoを使用した方が良い局面は非常に稀です。
私が言いたいのは
「稀であってもgotoを使用した方が良い場合は確実に存在するので、
gotoを一律に禁止とするのはいかがなものか」
です。

#あなたはunix屋さんじゃないでしょ。

>>700をベースにこんなん書いてみた。
enum { not_incomment, find_slash, incomment, find_aster } state;
for (state = not_incomment;;){
  c = getchar();
  switch (c) {
  case EOF:
    return;
  case SLASH:
    if (state == not_incomment) state = find_slash;
    if (state == find_aster) state = not_incomment;
    break;
  case ASTER:
    if (state == find_slash) state = incomment;
    if (state == incomment) state = find_aster;
    break;
  default:
    if (state == not_incomment) {
      putchar(c);
    }
    if (state == find_slash) {
      putchar( SLASH );
      putchar( c );
    }
  }
}
goto使わない方が融通きくと思うんだけどなぁ。

>>699が読みやすいとかエレガントだとかいうやつと一緒に仕事をしたくないなぁ。

取り敢えず、
　　「>>699 みたいなコード書く奴に書き直しを命じると
　　>>700 みたいなコードを書いて来るので
　　寧ろ別の奴にやらせた方がいい」
ということは判った。

補足。
　　「なんで4状態? 『コメント中か否か』の2状態で書けるだろ?」
くらいの助言をして、もう一度書き直させるかも。

>>124は使えない奴ということで

リファクタリングの技法のひとつに
gotoを使ってインデントレベルを下げる
というのがあるのを知らんの？

無理やりだなwwww

おまえらって・・・

インデントが深い事と
gotoを使うことのどちらが罪深いか



gotoの方が悪だと思う人間が多いだろうが、どちらも主観だな。

というか、インデントが深かったら関数化する、とかのほうがまっとうじゃねぇか？

>>729
>>707はstateの状態数が2になっているけど、
その分状態を管理する変数がstateとcの2つになっている。

>>736
なってないよ。

>>736
石川梨華はウンコしないよ。

リファクタリングを語るなら最低『リファクタリング』を読んでおいて欲しいものだ。

コードをさらすと話がすこしわき道に逸れますね。
>>124と>>725での主張に対する真正面のレスを希望します。

>>726　力作ですね。まだ全部は解析できていません。
＞goto使わない方が融通きくと思うんだけどなぁ。
支持はしませんが、反対もしません。主観に属する事項だと思いますので。
#私の主観は「>>726は難しい」です。

>>728-729
データの取得単位が1byteなので、４状態が正しいのです。
#まあこれも「わき道」なのですが。

>>124
主観以上の話ができないんだったら、もう来なくていいよ。

while (1) {
　　c = getchar();
　　if (c == EOF) {
　　　　break;
　　}
　　if (c != SLASH) {
　　　　putchar(c);
　　　　continue;
　　}
　　c = getchar();
　　if (c != ASTER) {
　　　　putchar(SLASH);
　　　　putchar(c);
　　　　continue;
　　}
　　while (1) {
　　　　while ((c = getchar()) != ASTER) {
　　　　　　;
　　　　}
　　　　c = getchar();
　　　　if (c == SLASH) {
　　　　　　break;
　　　　}
　　}
}

>>742バグ入りです。

>>740
726が難しいってオマエ馬鹿か？
オマエみたいな無能な奴がいるから(ry

switchがなく代わりに==, !=, break, continueが
ちりばめられたソースはとても素敵です。

>>742
今までで一番見やすいソースだ。
あ、全角でインデントしているからじゃないぞｗ
意図が一番良くわかる。トリッキーでもないし。
バグがあるそうだがｗ

>>740
>>726が難しいと思って、自分では>>699のようなコードを書く奴のことを世間では
馬鹿というようです。プログラマ止めてください。
それからウザいのでもうこのスレに書き込まないでください。

>>742
そもそも何回も入力を受けている段階で
プログラムの意味合いが全く違うと思うのだが。

んなこたーない。
常にEOFに気を配っていれば…だけど

そもそも前提が699だからな

普通、構文解析するときはもっとちゃんと組むだろよ
とりあえず/**/だけでいいんでしょ？

字句解析ではなくて？とか不要な突込みをしてみる

>>742
goto云々の問題ではない。
フローチャートから勉強しろ。

このあたりのコーディングスタイルなんてとっくの昔に確立してるんだから
ウダウダ考えてわけわからんコード撒き散らす前に既存のコード嫁。

主題から逸れてばかりですね。 私の主張に対するレスや、699がダメな理由を論理的に書いたレスが欲しいです。
「見慣れていないから拒絶する」という感情的な理由が後ろに見えるようなレスではなく。

>>741 わかりやすさを定量化する方法を提示してください。

>>742
綺麗ですね。
700などより742のようなプログラムを評価する人が少なからずいることを認めます。
#「742が700より一歩699に近づいている」という印象を受けるのは私だけか。

>>744
あなたが私のことを馬鹿だと思うのは勝手です。複雑さを理解する能力は個人差があるでしょう。
「平均より複雑さを理解する能力の高い人」は、そのことを自覚せず、自分の理解出来るレベルでプログラムを書くのでかえって危険です。 つまり「その人より複雑さを理解する能力の低い人」が、理解できないプログラムを書いてしまう傾向があるからです。
PGの複雑さについてのスキルは「複雑さを理解する力」ではなく「複雑さを十分理解出来る単純さに分解しそれを再構成する力」です（別スレでも書きましたが）

>>747
＞それからウザいのでもうこのスレに書き込まないでください。
楽しいからイヤです。疲れたら書き込まなくなるかも知れませんけど。

>>750
はい。構文解析を行うのが普通です。
不完全な仕様定義です。文字列定数やプリプロセッシングのことも考えていませんし。

貴殿には
>複雑さを十分理解出来る単純さに分解しそれを再構成する力
が無いように思えるが

>>754
>#「742が700より一歩699に近づいている」という印象を受けるのは私だけか。

あってます。俺は>>699を焼きなおしただけだから。
単純に置き換えていったらエンバグしたんだけど、めんどくさいのでそのままレスした。

バグの有り無しはおいといて、>>699のようなコードと>>742のようなコードを比べた
場合に、>>699は「さて読むぞ」という心構えをしないと読めないのに比べて、
>>742は「じゃ、上から読もう」と気楽になれるのではないかと思います。

continueもbreakもgotoと意味的にはそれほど変わらないんですけど、見た目の
印象が違うだけで、わかりやすさも違うような気にさせることができると思います。

>>756 ううっ。良いレスを有難う御座います。
＞continueもbreakもgotoと意味的にはそれほど変わらないんですけど、
同感です。#でも私がそれを書いたらまた叩きが増えたでしょうね。

＞見た目の印象が違うだけで、わかりやすさも違うような気にさせることができると思います。
そうですね。主観ですが、
699は、難しそうで気合を入れて読んでみたら理解できた。
742は、単純そうで気楽に読んでみたら見た目より難しかった。
の印象があります。

>>700は？

>>758 わずか３分で「突っ込み」がきましたか。
状態を表す変数の数は、699は0、700は1、742は0。ネストレベルは、699は0、700は2、742は3。
700は状態を表す変数を導入することにより、ネストレベルを一段階減らしている。
また、699はgotoを使っている。
等々の「わかりやすさ」を測定するスケールはいろいろありますが、全てのスケールを発見することは無理です。
それらの各測定値の重み付けについても、万人が納得するものなぞ出来ないことを御理解いただきたい。
わかりやすさというのは主観なのです。
だから回答は「ご自分で判断してください」です。

#私は３種の内、選択が可能ならデバッグするのも保守するのも699の書き方を選びます。

>>699
が一番読みやすかった。
labelが適切だと、コメント代わりにもなる。
while + continue は、ネストしているとcontinueがどのループに戻るのか
分からなくなるときが在る。
ちなみに、yaccの吐き出すCソースは、gotoのあらしだったような気がする。

>>699が一番読みやすいだなんて信じられない。
化石言語出身なのか？

俺は無視ですか？

>>762
いやあの。無視するつもりなんてないんだよ。
ただ印象か深くないというかなんというか・・・
711でレスが付いているじゃないか。

>>761
藻前、もしかしてインデントつけないで読んでねーか。

インデントついても読みにくい

enum { not_incomment, find_slash, incomment, find_aster, end} state;
state = not_incomment;
while( state != end ) {
　c = getchar();
　if ( c == EOF ) state = end;
　switch( state ) {
　case not_incomment:
　　if ( c == SLASH ) state = find_slash;
　　else putchar( c );
　　break;
　case find_slash:
　　if ( c == ASTER ) state = incomment;
　　else {
　　　putchar( SLASH );
　　　putchar( c );
　　　state = not_incomment;
　　}
　　break;
　case incomment:
　　if ( c == ASTER ) state = find_aster;
　　break;
　case find_aster:
　　if ( c == SLASH ) state = not_incomment;
　　else state = incomment;
　　break;
　default:
　}
}

switch〜case使ってステートマシンにしてみた。
if〜elseが読みにくいが改行を少なくするためなので勘弁。

おっと、自分も含めこれらには//*や**/を見逃してしまうというバグがあるのでは。
//*はともかく**/は*******************/という行がよくあるので対処の必要が
あると思う。

というわけで対処版。

enum { not_incomment, find_slash, incomment, find_aster, end} state;
state = not_incomment;
while( state != end ) {
　c = getchar();
　if ( c == EOF ) state = end;
　switch( state ) {
　case not_incomment:
　　if ( c == SLASH ) state = find_slash;
　　else putchar( c );
　　break;
　case find_slash:
　　if ( c == ASTER ) state = incomment;
　　else if ( c == SLASH ) putchar( SLASH );
　　else {
　　　putchar( SLASH );
　　　putchar( c );
　　　state = not_incomment;
　　}
　　break;
　case incomment:
　　if ( c == ASTER ) state = find_aster;
　　break;
　case find_aster:
　　if ( c == SLASH ) state = not_incomment;
　　else if ( c != ASTER ) state = incomment;
　　break;
　default:
　}
}

内容はともかく、お前らこんな不細工な書き方すんの？一行に複数の文を書くやつ。
括弧を付ける付けないはともかく、行変えたほうがいいんでねーの？
その点では>>742が一番見やすい。括弧過剰気味だが。

教科書大好きって感じだなw

>>770
最初はそう書いてたのだが、「改行が多すぎます」と怒られた。
普段書いてる下括弧でなく右括弧で書いたのも改行を減らすため。

まだ goto 使った状態遷移は解析し易くていいよ。　テーブル使った状態遷移なんて・・・・

俺だったらstrstr()使うかungetc()使うな（趣旨違い）。

>774
趣旨違いっつーか
ばかすぎ。

使うならstrtokじゃない？
StringTokenizer？

>>775
なぜ、ばかすぎなんだ？

>777
無駄な処理が増えるからだろ。

>>773
それ分かる気がする。
関数のポインタがテーブル化されてて、至る所から飛び回っているソースなんか特にそう。
作ってる本人は美しいと勘違いしているらしいが、他人にとっては解読しづらいだけ。
Simple is best!

ぶっちゃ毛VC++の仮想関数はテーブル化された関数ポインタそのものである訳だが。

strtokはマルチスレッドでは使えない

773が言ってる　テーブル使った状態遷移ってのは

abc って検索なら tbl[3][256]
tbl[0]['a'] = 1
tbl[1]['b'] = 2
tbl[2]['c'] = END

としといて

while(*p){
状態変数 = tbl[ 状態変数] [ *p++];
if( 状態変数 == END ) みつかった
}
って検索する奴でしょ？

これは自分でテーブル用意するんじゃなくて
機械的に変換するもんだと思うけど

>>781
なんで？

>>783
最初に呼び出すときには検索対象の文字列を指定するが
2度目以降は NULL を渡す。
ということは、次に検索する文字列 (へのポインタ) を
内部で保持しているわけで、
他のスレッドから strtok() を呼び出してしまうと
その内部ポインタを書き換えてしまうから。

勿論、他のスレッドでは使っていないのなら
使用してもいいわけだが。

同じ理由で、再帰呼び出し中にも注意しないといけない。

そんな使い方する気は無いけど、MSDNには

>これらの関数を同時に複数のスレッドから呼び出すことによって障害が発生することはありません
と書いてありますが……

WindowsにはTLS(Thread Local Storage)があるので、たぶんそれを使っているのでしょう。
実装依存なんで、ライブラリのマニュアルを読んで
マルチスレッド対応かどうか確かめてから使いましょうってなとこだな。

MainThread以外のTLSは明示的に生成しないと存在しないが？

>787
メインスレッド用のTLSも生成しなきゃ存在してないよ。

>>785-786
歯痛処理されてるって意味だろ。

シングルスレッドでも怖くて使えない物をわざわざマルチスレッドで
使えるようにしなくてもいいのにねぇ。

>>789
シングルだったらいいじゃねぇか


トークン検索って他にあるっけ？

危険を承知で使うか、自作してバグ作りこむ危険を冒すか迷うよな。

>791
おまいはプログラムをつくるな

>>790
下請けの関数が呼んでたら？
呼び出し元の関数が呼んでたら？

普通に考えて使えない。使うのはBASICとかFORTRANの出身のやつで
Cに馴染めてない初心者。
こういう奴はグローバル変数もやたら使いたがる。
負の依存性の固まりみたいなソースで、怖くて変更が出来なくなる。
典型的な旧世代方式だろ。

原始的なOOレベル(ハンドル)でも解決できる問題だろ？

>>793
旧世代てのはいつのことだ　ばーか

>>793
低脳グループと一緒にしないでね

>>794-795 ﾆﾎﾟｰﾝｺﾞ　ﾑﾂｶｼｲﾉ？

>>796
ﾌﾟﾛｸﾞﾗﾑ ﾑﾂｶｼｲﾉ？

>>794-795
strtokツカイモノニナラナイト、ワカラナイオマエハ
wantokダロ。

>>794
現状動いているコードは絶対に触るべからずという考え方を持った世代だな。

>>795
意味不明かつ無意味なレスして楽しい？
憂さ晴らしになってる？
たしかにリアルワールドじゃ誰も君を相手にしてくれないからね。
よしよし。

>>799
>意味不明かつ無意味なレスして楽しい？
>憂さ晴らしになってる？
>たしかにリアルワールドじゃ誰も君を相手にしてくれないからね。
>よしよし。

お前もな。無意味だな。

正直 >>124 の主張とやらが良くわからん。

>私が言いたいのは 「稀であってもgotoを使用した方が良い場合は確実に存在するので、
>gotoを一律に禁止とするのはいかがなものか」です。
と言っている以上、誰もが納得できる「gotoを使用した方が良い場合」を >>124 は提示するべきだと思うが、
では >>699 が正にその場合なのかと問えば
>前者と後者はどちらがbetterかという話ですが、私は前者がbetterであると判断します。書き易さも読み易さも
>保守性も断然、前者が優れています。ですが、後者の方がbetterであると判断する方もいてもおかしくはないです。
だという。。。
しかも、それでいながら
>699がダメな理由を論理的に書いたレスが欲しいです。
とは。

試みに >>124 の論法を真似てみる。

>>124:私は、娘。メンバーの中では「ののたん」が一番可愛いと判断します。
ですが、そうではないと判断する方もいてもおかしくはないです。
・・・
>>124:主題から逸れてばかりですね。「ののたん」がダメな理由を論理的に書いたレスが欲しいです。

うぬぅ、まずはののたん…じゃなかったgotoが有用だと判断する理由を論理的に書いて欲しいのだ。

>>793
ハ ハ ハ
一生ビクついて生きてろカスが(プププ!

>>801
＞誰もが納得できる「gotoを使用した方が良い場合」
を示すつもりはありません。
また「誰もが納得できる理由」が存在するか否かも疑わしいと思っています。
699がbetterであると思う人間が、私のみならず、例え１％でも存在すれば、「gotoを一律禁止とするべきではない」と考えます。

「699がダメな理由を論理的に書いたレスが欲しいです」と書いたのは、明確な理由もなく否定するレスが多く、反論そのものが出来ない状況だったので、
せめて「論理的にダメな理由」をレスしてくれれば反論が可能（かも知れない）と考えたからです。
ダメならダメでその理由を書いてくれなければ反論のしようがありません。

>>802
gotoは最初から存在します。
その後、ダイクストラを皮切りに、ストラクチャード定理により
「全ての論理は連接反復選択の三種の制御構造で表現することが可能である」
ことが証明されました。そして数多の伝道者によってストラクチャードプログラミングが普及しました。
ここで指摘したいのは、誰も「全ての論理は連接反復選択の三種の制御構造で表現するべきである」
ことを証明した人はいないと言うことです。
まずgotoありき。そののちにストラクチャードプログラミングが生まれた。
ならばストラクチャードプログラミング原理主義側がgotoを一律禁止とするべき理由を示すべきでしょう。

追加
>>802
あえていうなら
「699、700、742のなかで699を選択する人間が存在するから有用である」
となりますが。

「禁止する」なら「誰もが納得する」禁止する理由を示すべきなんじゃ？

gotoは低レベルな概念であり、より良い選択肢を駆逐する可能性があるため禁止するべきである。
例）breakで済む処理をgotoで実装することに何の罪悪感も感じない馬鹿。
しかし、全てを理解した上で絶望の山を駈け上がる愚者には何も言うべきでない。
例）パフォーマンス測定の結果、最大のボトルネックが発見された。
アルゴリズムは理論上最速のものだがまだ速度が足りない。
システムの全パフォーマンスはこの関数のアセンブリレベルでの最適化の成否にかかっているッ！

あ、アセンブリ埋め込みで書けばgoto文いらないや（汗

goto使う奴の頭はおかしい

第２ラウンドですか？（いや、第３ラウンドか？）

>>754から抜粋＆無理矢理変更
「gotoを理解する能力の高い人」は、そのことを自覚せず、自分の理解出来るレベルで
プログラムを書くのでかえって危険です。 つまり「その人よりgotoを理解する能力の低い人」が、
理解できないプログラムを書いてしまう傾向があるからです。

普通、初心者には「gotoを使うな」もしくは「初心者のうちはgotoを使うな」といいますからねぇ。
初心者から脱しても「gotoを理解する能力の低い人」は多いと思いますよ。

>>804
>gotoは最初から存在します。
>その後、ダイクストラを皮切りに、ストラクチャード定理により
>「全ての論理は連接反復選択の三種の制御構造で表現することが可能である」
>ことが証明されました。そして数多の伝道者によってストラクチャードプログラミングが普及しました。
>ここで指摘したいのは、誰も「全ての論理は連接反復選択の三種の制御構造で表現するべきである」
>ことを証明した人はいないと言うことです。
>まずgotoありき。そののちにストラクチャードプログラミングが生まれた。
>ならばストラクチャードプログラミング原理主義側がgotoを一律禁止とするべき理由を示すべきでしょう。

ならば全てのコンピュータは真空管・パンチカード・コアメモリ等を付けて
売らなくてはいけなくなるな・・・
個人的にはオペレータのお姉さん添付キボン。

>>810
オペレータのお姉さんを悪用・濫用する人が多いので禁止するべきです。

理解容易性は神への信仰の次に大切なのです。
まーちんふぁうらー著・りふぁくたりんぐ

つまりあれだ。goto使う邪教徒共はお望みどおりに
goto HELL;

http://pc.2ch.net/test/read.cgi/prog/1049904397/589-594

>gotoを使っている人は、gotoをなくせないからgotoを使っているの
>ではなく、gotoを使ったほうが美しい構造を保てるから、gotoがなく
>せることを理解した上でgotoを使っているのである。


何でも言ったモン勝ちだなぁ
性格悪くて金ばっか掛かる女に、だまされてるのは分かってるけど、その女が美しいから金を貢ぎ続けるのですね
客観的に見たら馬鹿ですね
そんなアタマだから
>gotoをなくせないからgotoを使っている
んだろうね

goto=性悪女で　ファイナルアンサー？

まだ、Cにswitchやforが標準化されてなかった時には
よく使ったなぁgoto

>>807
＞gotoは低レベルな概念であり
すこし違います。gotoはrawレベルですがlowレベルではありません。
＞より良い選択肢を駆逐する可能性があるため禁止するべきである。
「より良い選択肢を駆逐する可能性がある」というのは曖昧過ぎませんか。
「面倒だからgotoを使ってしまう」というパターンを懸念されているのなら、
それはコードレビューを行わない組織文化を意味し、そのような組織文化は
「gotoを使っていないから悪いプログラムではない」などという単純な二元論に陥りやすいのです。
こんな命題が成立しないのはご承知だと思いますが。
＞全てを理解した上で絶望の山を駈け上がる愚者には何も言うべきでない。
規則化されないなら私は何も言いません。
「絶望の山」だとも思いません。gotoが有用だと判断したら、使うだけです。

>>809
なるほどねえ。
確かに699のようなプログラムにおけるラベルが20個所（20ステート）以上になっているようだとスパゲティだとの非難は免れませんね。
だけど699はわずか4箇所です。
４箇所のとび先で「gotoを理解する能力の低い人」には理解できないと仰っているとは思えません。
ですから「699のプログラムがわかりにくい」との表明は「感情的な反発」と判断しています。
＞初心者から脱しても「gotoを理解する能力の低い人」は多いと思いますよ。
はい。これだけ構造化構文を備えた言語が一般的であるという現状から鑑みて、
実務でgotoを見たことのない人も少なからずいるでしょう。
このことが「私が感情的な反発であると判断」する理由の一つでもあるのですが。

>>814
Linuxカーネルのソースを読んでごらん、
プロセスのスケジューリングあたりが良いかな。

とりあえず、goto使わない目的でwhileとか使うのはやめてほしい。

コンパイラがC++対応なら、試す＆投げる＆掴むを使おう！
生成物のサイズがちょっとでかくなるけど・・・。

処理系がC++対応じゃなかったら？

for(;;)

813は京都の狂犬こと近藤だから無視してください。
おまえもこんなところで粘着してないで
とっとと新しい職をさがして家族の負担を
無くせよ。４０男の独身素人童貞が。

また力作ですが(w >>769がベースです。話のタネにしてください。
enum { OTHER, SLASH, ASTER, TOKEN_MAX };
enum { not_incomment, find_slash, incomment, find_aster, state_max };
int char2token[CHAR_MAX]; /* CHAR_MAXでよいか？ */
void dummy(int c) { }
void action_c(int c) { putchar(c); }
void action_sc(int c) { putchar('/'); putchar(c); }
struct {
  void (*action)(int c);
  int next;
} state_table[state_max][TOKEN_MAX] = {
  {{ action_c, not_incomment }, { dummy, find_slash }, { action_c, not_incomment }}, /* not_incomment }*/
  {{ action_sc, not_incomment }, { action_c, find_slash }, { dummy, incomment }}, /* find_slash */
  {{ dummy, incomment }, { dummy, incomment }, { dummy, find_aster }}, /* incomment */
  {{ dummy, incomment }, { dummy, not_incomment }, { dummy, find_aster }}, /* find_aster */
};
int main() {
  int state = not_incomment;
  int token, c;
  char2token['/'] = SLASH;
  char2token['*'] = ASTER;
  while ((c = getchar()) != EOF) {
    token = char2token[c];
    state_table[state][token].action(c);
    state = state_table[state][token].next;
  }
  return 0;
}

>>818
Linuxはクソ
書いた奴もクソ

>>824

良くできました

一週間かけてこんなことやってたのか？

gotoを使う奴はアウトローなんだろ。
法律から外れても融通を利かせようとしてるタイプ。

goto禁止主義者は糞マジメなんだろ。
多少理不尽でもルールに従う事が大事なタイプ。


俺はルールに従う事を選ぶがね。
小さな混沌は必ず大きな混沌へと変わっていくからな。

ラベル付きbreakの無い言語はgotoを使う。盲目的に非難するのはﾊﾞｶのやること。

別にgotoを非難するつもりは無いが、>>699は非難する。
テストしづらいやん。

初心者はgoto禁止にすべきだが、ある程度の経験が有れば
エラー処理等に使う場合限り使用しても良いと思うが・・・
>>825
なんか痛い目に合いましたねｗ

これだけgoto禁止が広まってると
「gotoは使ってはいけない」
という言葉だけを知っている初心者の方が多そうだけどな。

プログラム初心者時代をベーマガで過ごし、
構造化→OO→ジェネリック→ジェネラティブと順調に進んできている俺には
gotoは手戻りに思えてならん。
それでも効率の為に敢えてgotoを使うならわかるが
gotoを使ったほうが美しいと感じるセンスには共感できん。

なんかオレを使うなとか使えとか、どっちやねん

#まともなレスが増えてきたような。

>>830
ブラックボックステストではなく、「ホワイトボックステストやデバッグが難しい」ですね。
それは699に限った話ではなく、この種の「データの入力単位を1byteにしたプログラム」の宿命であると思いますが

>>828
私はgoto一律禁止の規約があるところで開発を行う羽目になったなら
700のようなプログラムを書くでしょうね。生産性は落ちると思いますが。
ところで「goto一律禁止の規約」って実在しますか？「極力使用しない」との記述は何度か見ましたが。
＞小さな混沌は必ず大きな混沌へと変わっていくからな。
ご見解には三点ほど疑義があります。
goto使用一律禁止をルールで決定されているという前提で記述されていると思える点。
そのようなルール下での開発しか世の中には存在しないという前提で記述されていると思える点。
仮にgotoに付いてのルールが「極力使用しない」であった場合、gotoを使用することにより発生する（かも知れない）
小さな混沌が、大きな混沌に変化することに対する有効な予防策が存在しないことを前提に記述されていると思える点
の三点です。

>>833
誰もgotoが美しいとは思っていないと思うよ、それでも
あえてgotoを使える様になって初めて初心者を卒業では？
まあ漏れは制御系だからアプリ系とは違うと思うが。

もーどーでもいーよー

>>835
＞goto使用一律禁止をルールで決定されているという前提で記述されていると思える点。
構造化フロー制御はかくあるべきであるとダイクストラさんが決めたんだって。

＞そのようなルール下での開発しか世の中には存在しないという前提で記述されていると思える点。
それは深読みしすぎっす。
あくまで構造化フロー制御というルールが前提である場合の話っすから。
それとも構造化フロー制御からひっくり返します？

＞仮にgotoに付いてのルールが「極力使用しない」であった場合、gotoを使用することにより発生する（かも知れない）
＞小さな混沌が、大きな混沌に変化することに対する有効な予防策が存在しないことを前提に記述されていると思える点
一文が長いっす。文章も`Divide and conquer!!'でお願いしますよ。
で、その曖昧な事象に対する具体的な予防策はあるんですか？

>>835
broken window theory

>>699はある行に至るルートが複数存在する。
つまり、修正や機能拡張が難しいということ。
よって却下。
自分が修正すれば大丈夫というのは通用しないよ。

>>838
＞構造化フロー制御はかくあるべきであるとダイクストラさんが決めたんだって
>>124と>>804がレスです。
＞それは深読みしすぎっす
失礼しました。
＞それとも構造化フロー制御からひっくり返します？
はい。「構造化フロー制御」は全能ではありません。>>124がレスです。
＞一文が長いっす。
失礼しました。
＞具体的な予防策はあるんですか？
こちらが答えるべきであるかどうか・・・は別として、
コードレビュー／ウォークスルー／インスペクション等でしょう。
「言うことが古い」かも知れませんが。

#なんか私が苛めてるみたいなやり取りになってしまいましたね。ごめんなさい。

みんなの能力がこんなこと問題にならないくらい高ければ別に良かったのにね




実際には>>124みたいなのが居てダメだと言うことで

GOTOは我がBASICプログラマーの宝です！
これだけ忘れんといてね。

BASICプログラマーの宝はONGOTOだと思うんだが。

http://www.geocities.co.jp/Milkyway-Orion/3324/prog/realprog.html

>>844
一緒だろーがっ！眠いのに揚げ足とんな、簿毛！

>>845
20年前の文書を持ち出してなんだといいたいんだろう？

>本物のプログラマはBASICなど書かない。
>一般に、12歳以上になってBASIC を書くプログラマはいない。

えーと。。。僕はまだ11歳だからへっちゃらだねっ！
つーか、845市ね！！！

そのページにあるリアルプログラマーって一種のジョークですよ
要するに自分が「本物だ」と思い込んでいるやつこそニセもので
滑稽なものだって言いたいための。

本当のプログラマは常に自信が無いのです。

自分のコードが完璧であるという自信が無いから、バグを出さないように慎重に組むし、
スケジュールを守れる自信が無いのでツールを駆使して作業効率を上げるよう努力し、
自分の知識に自信が無いから常に新しい言語や技術を覚えようとします。

自信たっぷりなプログラマはたいがいが初心者。

漏れは本当のプロ・グラマーでつ、ｓｗの究極はマイクロコードに
成ります、このスレはゴミばかりですね！！！

>>825
ある時期から
unixは　ど素人がプログラムを
書くようになったみたいだな

そりゃ自信のない人間は小心者だよな

gotoを嫌う人はswitch-caseも嫌い？
インデントが違うだけだよね？それが重要なの？

>>852
素人っていうか、驕ったバカじゃない？

人の書いたソースのgotoの使い方に賛同出来たら、それを真似すれば良いと思う。
問題は、そういったソースを見れる機会が少ない事かな。

>>852
お前OSを描けるのか？アプリしか出来ないゴミが
OSの批判をするのはお笑いだよ。

>>856
お前バカか？ソースなんか山の様に有るだろう、
MSしか知らないのか？？？

OS書かないとゴミなのか？
OS書くにはパフォーマンス上gotoが必要かもしれないが、
ソースを書く側も読む側も承知してるからok。
でも、一般には違うべ？

>858
山のように有るのか。教えてくれてありがとう。
ついでに紹介してくれるとありがたいんだけど。
gotoの使い方に賛同出来るソースを。

なんかﾁｮﾄUNIX/Linux使ってるだけでOS作れると思ってる奴が居るようだな







ということはこういう馬鹿がgotoを使うのか
せっかくだから今日から後藤と名乗れや(w

漏れはOS（リアルタイム）の移植も仕事なんで、
お前らミタイな素人とは話が合わないわけだｗｗｗ

>>862
ソースまだー？

あと、上げないでね。

>>862移植

なんか作ることと真似ることを一緒に考えてる馬鹿がいるな

>>859
一般の意味がお前らのようなアマグラマーを指すのであれば
そのとうりだな、VC++でゴミ・アプリでも作ってろ。
>>860
自分で作れ！！！
>>861
お前のようなバカは放置だな。

アタマ手遅れか……？
誰でも出来ることを自分しか出来ないと思ってる
ｶﾜｲｿｳ

残念だけどプログラムなんて普通の頭の奴がちょっと勉強すれば誰でも出来ることよ？

いまどき、構造化なんていう視点でプログラムを見る時代でもないだろう。

上げてる方へ。

学生の間はこんな所で遊んでないで、しっかり勉強しなさい。

まあ上げる価値も無いスレでつね。

ハッキリ確認しておくが
gotoが悪い訳じゃない

gotoを安易に使うバカが悪い

Javaはgoto狂信者がストライキ又は暴動を起こす可能性を踏まえて、
gotoを予約語にして将来の拡張の可能性を残しました。

でも、gotoなんか要らないってことに利用者が気付いてくれたたから、
永遠にgotoは予約語のままなのです。めでたしめでたし。

>>872
お前玄人童貞だろ、gotoした時の快感を知らないなんて
可哀想だなｗｗｗ

俺の名前を勝手に予約語にするなよ

>>869
そろそろ引退したほうがいいんじゃないでしょうか？

gotoは使うがdo{}whileは使わない。
こんなもん使うならif〜breakに置き換えるよ。

漏れ的にはgotoどころではなく、Cのインデントの付け方に
そろそろ統一した規格がほすいんだが。でもtabは4にしてね・・・

>>877
Ema糞ユーザーを死滅させれば自然とタブに統一するよ。
幅は各自勝手に決めればいい。

>>878
漏れはリナックスもVスタジヲで作っているおバカなんだよ！！！
tabは絶対4に汁、これは漏れのお願いだよ。

\tの表示幅は各自勝手に決めればいい。

何？空白を使っている？
「ちょっとハンドル持っててくれ」
ぱきゅーんぱきゅーん＞＞＞＞>>879
ばたっ。

「よし」

★の箇所でループ文を抜け出したいときに
break;、contenue;を使わず処理２にを処理したいときにgotoを使うなもれ。

//ループ１
while(){

//ループ２
while(){//
if()goto koko;　//★
}
・・・処理１
koko:
・・・処理２
}

ループ２をてっとり早く抜け出す方法ってあるのかな？
また、ループ２内のcontenue;はループ１の先頭になるのだっけ？

//ループ１
func(){
while(){

//ループ２
while(){//
if(){
・・・処理２
return;
}
}
・・・処理１
・・・処理２
}
}

>>882
条件として、

処理２をしてもループ１を終了する判断材料にはならない。

>>881
設計し直せ

>>884の脳内
設計＝コーディング

いきなり客層が変わったな・・・

>>885
ﾊﾟｶ?

>>882,884
こういう処理があるのを想定できない奴なのか？

だいたい、882のreturnだと、break;と同じでしょう。

break 2; // ループのネストを２個抜ける
見たいな命令が無いのはなでだろ。
あってもおかしくないよな。

>884
マ板のあほ達ですから(´,_ゝ｀)ﾌﾟｯ

>>888
オマエテーノー

>>889
for(){
for(){
breakto hoge;
}
}hoge:
の方がわかりやすくないか？

タブとスペースでもめてる方々へ
インテンションプログラミング！

gotoをjmpに改名しようぜ
アセンブラと同じにすればイメージ悪くない

>>892
それ、いいな。ループにラベル付けてラベルをしてして抜ける。
特定の条件でループをまたいで抜けたい場合なんかに使えそうじゃないか。
そうすれば奇妙な goto + ラベル は少なくなるんじゃないか。

説明不足だったので追記。

ループ２を抜けてもループ１は抜けてほしくない場合のことをいってる。

for(;;処理２){
　while(){
　　if(){
　　　flag = 0;
　　　break;
　　}
　}
　if(flag){
　　処理１
　}
}

>>896
漏れの場合、そういう場面に出くわしたら、
while(){//
if()goto koko;　//★
}
を別の関数に分けて、戻り値で条件分岐だな。もっとも while() の中身によるが。。
20step を超えるようだと別関数、それ以下ぐらいなら goto を使う。

>>898
だよね、レスどうもありがとう。

パフォーマンスの必要な
デジタル信号処理でもgotoは使わんな

>>899
基礎にもどりましょう
フローチャート書いて
gotoが無くなるように考えてみましょう

>>900
あまり例外的な流れが発生することが無いからね。

ttp://www.google.co.jp/search?q=%E3%81%AC%E3%82%8B%E3%81%BD&ie=UTF-8&oe=UTF-8&hl=ja&lr=

>>804
あんたの言ってる事はつまりこういう事だ。

強姦は最初から存在します。
その後、宗教を皮切りに、風習や文化により
「人類の繁殖は和姦で済ませることが可能である」
と思われるようになりました。そして数多の伝道者によって婚姻制度が普及しました。
ここで指摘したいのは、誰も「和姦で済ませるべきである」
ことを証明した人はいないと言うことです。

まず強姦ありき。そののちに和姦が生まれた。
ならば和姦原理主義側が強姦を一律禁止とするべき理由を示すべきでしょう。

>>904は>>841へだな。

>>904
滅茶苦茶です。「goto使用を犯罪である」との前提で話をして、何かが得られるとお考えですか。
言い負かすためだけの理屈に見えますよ。仮にあなたが私を言い負かしても、私はgoto使用をやめるつもりはありません。
「goto使用を犯罪である」と思っているのなら「犯罪である」という理由を書いてください。
#もしかして宗教／風週／文化が成立したからときから強姦が犯罪になったと同様に
#構造化プログラミングが成立したからときからgotoが犯罪となった。
#なんて事を書くのでしょうかね。

近代化した今の社会では強姦はただの悪だ。
近代化した今の言語ではgotoはただの悪だ。

原始的な社会においては対して悪いことではない。
原始的な言語においては対して悪いことではない。

C言語は近代化した言語とはいえないが。どちらかといえば原始的な言語だろう。
つまりCでgotoを使うのは必要悪ということさ。

マサイの戦士たちに、都会の慣習をムリヤリ押し付けるなんてのは愚の骨頂さ。

何をやっているか分からないうちは、gotoを使ってはいけませんよ。

ｸﾋﾞﾘｺﾛｻﾚﾃｼﾏｲﾏｽｶﾗﾈ

>>907　歴史は繰り返す。

>>907
ていうか
アセンブラのほうが構造化は大切だぞ

goto使う奴は高級言語使うな

goto -10;とかやって相対的な行へジャンプするようにすればいいんだよ。
これなら明示的かつ論理的かつ直感的だし。可読性下がりようが無いからバグもでない。

>>912
それはいんたーぷりたーか？