アカウント名:
パスワード:
1968年の論文を踏まえて無軌道にgotoを使わなくてもいいように言語仕様が設計されたりプログラマーが使用を自重するようになったんだろ。
今となっては goto 文を使う人は、そうした方が見通しいい場合に限り使っているという印象case break の方が危ういね
#一般のブロック抜けgotoが欲しい
> #一般のブロック抜けgotoが欲しい
C言語だと，ブロックを別関数にして return を使う，というのが一つの解ですね．
別関数にすると，関数呼び出しのオーバヘッドを気にする人がいますが，オーバヘッドは生じません．今時のコンパイラは最適化処理が賢いので，無駄な関数呼び出しは自動でインライン展開されます．
ただ関数にするとローカル変数をすべて関数の引数として渡す必要があるので，コーディングするときは少々面倒です．
最近のC++だともっと綺麗かつ効率良いコードが書けます．具体的には
std::vector<int> a = {3,5,7,13,17}; std::for_each(a.begin(), a.end(), [](auto x){ if (x>10) return; std::cout << x << std::endl; });
みたいな感じで，ブロックをラムダ式で記述して，return で抜ける，と綺麗に書けます．ローカル変数を渡すのも簡単です
ですので，goto使いたくなければ，C++で書く，というのは結構良い選択肢だと思います．
その例なら、ラムダ式を使わないようにするともっときれいに書けるよ。
std::vector<int> a = {3, 5, 7, 13, 17};for (int x : a) { if (x > 10) break; std::cout << x << std::endl;}
というか、もともと C/C++ の break だけで済むコードをわざわざラムダ式と return に書き直してくれても、何がきれいだと言いたいのかさっぱりわからないんだけど……。二重のループの外側を for_each とラムダ式で書くと、内側を抜けるのは break で、外側を抜けるのは return で書けるからきれいとか、そういう話? 僕はそういう書き方が特にきれいだとは思わないけれど。
いや、ごめんなさい、 break じゃなくて continue にしないと同じ挙動にならなかった……。ますます annoymouse coward さんが何を言いたいのかわからない。
元コメの意図に添えているかはわかりませんが、for_eachとかしない場合にラムダ式でreturnを呼ぶってことだと思いますよ。for_eachを強引にとめる方法はもうthrowくらいしか思い浮かばないですが。
たぶんこうしたかったんでしょ。この例だと簡単すぎて何の意味もないけど。
std::vector a = {3,5,7,13,17}; [&]{ for(auto x:a) { if(x>10){return;} std::cout x std::endl;
うーん、なるほど、 return で脱出するだけのためにラムダ式を作ってすぐ呼ぶということか。
二重のループから脱出したい、でも名前の付いた関数として分割するほどまとまった処理でもない、という場合に、その書き方は個人的には無駄に複雑な方法に見えるなあ。チーム内の取り決めとかでそういう書き方をすることになっていたら仕方ないけれど、そういう事情がなければ goto の方が数段マシな気がする。
スラッシュドットには <ecode> という謎要素があって、それを使うと不等号とかもよしなに扱ってくれるので、 C++ とかのコードをコメントとして書く場合にはお勧め。
> ますます annoymouse coward さんが何を言いたいのかわからない。
なまはんかな理解にもとづく「使いたがり」で使用するラムダ式は、gotoと同等以上の害がある。場合によってはgotoの方がよっぽどまし。
単なる書き方の例なんじゃねーの？ コードの内容ではなくてさ。ラムダ式の中に多重forループがあって、そこから一気に抜けたい場合とか。
まぁ例が適切ではないのかもしれないけど、趣旨は汲んで上げようよ。
例が適切でないだけかもしれないと思って趣旨を汲もうとした結果が、
二重のループの外側を for_each とラムダ式で書くと、内側を抜けるのは break で、外側を抜けるのは return で書けるからきれいとか、そういう話? 僕はそういう書き方が特にきれいだとは思わないけれど。
なんだけど……。
う、う～ん？これは綺麗なんでしょうか。
大分話がそれますが、Ruby の each に渡すブロック内での、break と return の挙動がどうもしっくりきません……。
switch の case と言えば昔C言語で、クラッシュの原因を探って行ったら、break 抜けだったことがありました。
今時のコンパイラは最適化処理が賢いので，無駄な関数呼び出しは自動でインライン展開されます．
そんな頭のいいコンパイラなんてあるかなあ? 関数の大きさとかで一律に判断してるとかじゃないの。そんな条件も最適化オプションで変わったりするし、インライン展開させたい/させたくないってときにはプログラマが#pragmaとかでいちいち指定するのがいまだに普通だと思うが。
「gotoはダメだgotoはダメだgotoはだめだ」って唱えながら、こんなことするくらいなら、gotoのほうが遥かにまとも
do { ... break; ...} while(0);
ごめんなさいdo {} while(false);多用してます…
だってラベル名考えるのがめんど（流石にこれやるとき多重ループは禁止にしてますが。
あとgoto使うと途中宣言が禁止されるのが苦手
久しくコーディングしていないけど、do { } while(0); はマクロ書くときくらいかも
自分なら末尾呼び出しを使う。
直感的にそうだろうとは思っていたけど、こうしてきちっと調べて、言葉にしてもらえるといいね
だね．こういう地道な研究はありがたい．# goto を見ただけで発狂するアホが昔いたもんで…
goto有害論によって有害な使い方を大勢が意識的に避けている現状での、原因と結果が逆な可能性を想定していない研究が地道な研究？君の言う事例でのgotoも実はgotoである意味のない、この論文で言う「Dijkstra氏が懸念したような無制限な使用」で、真っ当な忠告・批判だったんじゃないの？
そんな捉え方する様な奴が蔓延っているんじゃgoto有害論はまだまだ必要だね。goto有害論を踏まえた上で有益な場合にのみ使用する程度にしておかないと、有害な使い方を排除できないじゃないか。
さんざgotoを悪者扱いしてきた奴の言い訳っぽい
いまでも稀にgoto有害論の典型みたいなスパゲッティgotoは存在するから、そういうの見てから言ってくださいな。
言語はCなんだから言語使用は無関係と言えるのでは？
#ストーリーを読まなくてもすばらしい洞察。すばらしいですね。
E. ダイクストラのGo To Statement Considered Harmfulは1968年、C言語の誕生は1972年、仕様化はさらにその後ですから、「無関係と言える」と言えるかどうかは分かりません。
C言語はgoto文必要悪の思想をきちんと踏まえて設計された言語。構造化プログラミングの初代権化みたいなもんだ。68年の論文を待たずしてgoto文とスパゲッティ化は以前から言われていた。K&Rもその辺は意識してサブルーチンを廃して関数にしてしまっている。
カサンドラのジレンマですか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
原因と結果が逆 (スコア:5, すばらしい洞察)
1968年の論文を踏まえて無軌道にgotoを使わなくてもいいように言語仕様が設計されたりプログラマーが使用を自重するようになったんだろ。
Re:原因と結果が逆 (スコア:2, すばらしい洞察)
今となっては goto 文を使う人は、そうした方が見通しいい場合に限り使っているという印象
case break の方が危ういね
#一般のブロック抜けgotoが欲しい
Re:原因と結果が逆 (スコア:3, 興味深い)
> #一般のブロック抜けgotoが欲しい
C言語だと，ブロックを別関数にして return を使う，というのが一つの解ですね．
別関数にすると，関数呼び出しのオーバヘッドを気にする人がいますが，オーバヘッドは生じません．
今時のコンパイラは最適化処理が賢いので，無駄な関数呼び出しは自動でインライン展開されます．
ただ関数にするとローカル変数をすべて関数の引数として渡す必要があるので，コーディングするときは少々面倒です．
最近のC++だともっと綺麗かつ効率良いコードが書けます．具体的には
std::vector<int> a = {3,5,7,13,17};
std::for_each(a.begin(), a.end(),
[](auto x){
if (x>10)
return;
std::cout << x << std::endl;
});
みたいな感じで，ブロックをラムダ式で記述して，return で抜ける，と綺麗に書けます．
ローカル変数を渡すのも簡単です
ですので，goto使いたくなければ，C++で書く，というのは結構良い選択肢だと思います．
Re:原因と結果が逆 (スコア:3)
その例なら、ラムダ式を使わないようにするともっときれいに書けるよ。
というか、もともと C/C++ の break だけで済むコードをわざわざラムダ式と return に書き直してくれても、何がきれいだと言いたいのかさっぱりわからないんだけど……。二重のループの外側を for_each とラムダ式で書くと、内側を抜けるのは break で、外側を抜けるのは return で書けるからきれいとか、そういう話? 僕はそういう書き方が特にきれいだとは思わないけれど。
Re:原因と結果が逆 (スコア:2)
いや、ごめんなさい、 break じゃなくて continue にしないと同じ挙動にならなかった……。ますます annoymouse coward さんが何を言いたいのかわからない。
Re: (スコア:0)
元コメの意図に添えているかはわかりませんが、for_eachとかしない場合にラムダ式でreturnを呼ぶってことだと思いますよ。for_eachを強引にとめる方法はもうthrowくらいしか思い浮かばないですが。
Re: (スコア:0)
たぶんこうしたかったんでしょ。
この例だと簡単すぎて何の意味もないけど。
std::vector a = {3,5,7,13,17};
[&]{
for(auto x:a)
{
if(x>10){return;}
std::cout x std::endl;
Re: (スコア:0)
Re:原因と結果が逆 (スコア:2)
うーん、なるほど、 return で脱出するだけのためにラムダ式を作ってすぐ呼ぶということか。
二重のループから脱出したい、でも名前の付いた関数として分割するほどまとまった処理でもない、という場合に、その書き方は個人的には無駄に複雑な方法に見えるなあ。チーム内の取り決めとかでそういう書き方をすることになっていたら仕方ないけれど、そういう事情がなければ goto の方が数段マシな気がする。
Re:原因と結果が逆 (スコア:2)
スラッシュドットには <ecode> という謎要素があって、それを使うと不等号とかもよしなに扱ってくれるので、 C++ とかのコードをコメントとして書く場合にはお勧め。
Re: (スコア:0)
> ますます annoymouse coward さんが何を言いたいのかわからない。
なまはんかな理解にもとづく「使いたがり」で使用するラムダ式は、gotoと同等以上の害がある。場合によってはgotoの方がよっぽどまし。
Re: (スコア:0)
単なる書き方の例なんじゃねーの？ コードの内容ではなくてさ。
ラムダ式の中に多重forループがあって、そこから一気に抜けたい場合とか。
まぁ例が適切ではないのかもしれないけど、趣旨は汲んで上げようよ。
Re:原因と結果が逆 (スコア:2)
例が適切でないだけかもしれないと思って趣旨を汲もうとした結果が、
なんだけど……。
Re:原因と結果が逆 (スコア:1)
う、う～ん？これは綺麗なんでしょうか。
大分話がそれますが、Ruby の each に渡すブロック内での、break と return の挙動がどうもしっくりきません……。
switch の case と言えば昔C言語で、クラッシュの原因を探って行ったら、break 抜けだったことがありました。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
今時のコンパイラは最適化処理が賢いので，無駄な関数呼び出しは自動でインライン展開されます．
そんな頭のいいコンパイラなんてあるかなあ? 関数の大きさとかで一律に判断してるとかじゃないの。
そんな条件も最適化オプションで変わったりするし、インライン展開させたい/させたくないってときにはプログラマが#pragmaとかでいちいち指定するのがいまだに普通だと思うが。
Re: (スコア:0)
「gotoはダメだgotoはダメだgotoはだめだ」って唱えながら、
こんなことするくらいなら、gotoのほうが遥かにまとも
do {
...
break;
...
} while(0);
Re: (スコア:0)
ごめんなさい
do {} while(false);多用してます…
だってラベル名考えるのがめんど（
流石にこれやるとき多重ループは禁止にしてますが。
あとgoto使うと途中宣言が禁止されるのが苦手
Re: (スコア:0)
久しくコーディングしていないけど、do { } while(0); はマクロ書くときくらいかも
Re: (スコア:0)
自分なら末尾呼び出しを使う。
あつものに懲りて膾を吹く (スコア:0)
直感的にそうだろうとは思っていたけど、こうしてきちっと調べて、言葉にしてもらえるといいね
Re: (スコア:0)
だね．こういう地道な研究はありがたい．
# goto を見ただけで発狂するアホが昔いたもんで…
Re: (スコア:0)
goto有害論によって有害な使い方を大勢が意識的に避けている現状での、原因と結果が逆な可能性を想定していない研究が地道な研究？
君の言う事例でのgotoも実はgotoである意味のない、この論文で言う「Dijkstra氏が懸念したような無制限な使用」で、真っ当な忠告・批判だったんじゃないの？
そんな捉え方する様な奴が蔓延っているんじゃgoto有害論はまだまだ必要だね。
goto有害論を踏まえた上で有益な場合にのみ使用する程度にしておかないと、有害な使い方を排除できないじゃないか。
Re: (スコア:0)
さんざgotoを悪者扱いしてきた奴の
言い訳っぽい
Re: (スコア:0)
いまでも稀にgoto有害論の典型みたいなスパゲッティgotoは存在するから、そういうの見てから言ってくださいな。
Re: (スコア:0)
言語はCなんだから言語使用は無関係と言えるのでは？
#ストーリーを読まなくてもすばらしい洞察。すばらしいですね。
Re:原因と結果が逆 (スコア:2)
E. ダイクストラのGo To Statement Considered Harmfulは1968年、C言語の誕生は1972年、仕様化はさらにその後ですから、「無関係と言える」と言えるかどうかは分かりません。
Re: (スコア:0)
C言語はgoto文必要悪の思想をきちんと踏まえて設計された言語。
構造化プログラミングの初代権化みたいなもんだ。
68年の論文を待たずしてgoto文とスパゲッティ化は以前から言われていた。
K&Rもその辺は意識してサブルーチンを廃して関数にしてしまっている。
Re: (スコア:0)
カサンドラのジレンマですか。