アカウント名:
パスワード:
たとえば3つの逐次処理があって、エラーなら次に進まないとすると、gotoなしだとif (処理1が成功) { if (処理2が成功) { if (処理3が成功) { } }}となって逐次処理なのにネストっぽくなってしまう。ホントの条件分岐やループがあったら取り返しの付かない深さに。
if (処理1が失敗) { goto エラー終了}if (処理2が失敗) { goto エラー終了}if (処理3が失敗) { goto エラー終了}
のほうがやりたいことがストレートに書ける気がするんだ。実際、今回のコードもこんな感じ。
本来なら例外を使うべきところを、効率が求められるOS内コードなので goto で代用した、と考えると納得がいく気がします。
.cみたいなのでこのコードはC++ではなくCなのではないかと思います。そうすると例外機能がないので。
自分で確認はしてないですが、コメントに「同じディレクトリに.cppのファイル」があるという話なようですね。とすればプロジェクトは(恐らく)C++ も使える環境なんだろうと思うので何故このコードがCでないといけないのか不思議には思いますが…。
C++である場合、例外の実装ではオーバーヘッドは主に投げる時に発生し、投げない時には極力発生しないように工夫されているという話なのでチェックが失敗したときに少し遅くなる程度はそれほど問題にならない気もしなくはないです。(失敗した場合、それよりうしろのチェックの処理時間はなくなるわけだし。)
参考: 「C++オブジェクトモデル―内部メカニズムの詳細 」 [amazon.co.jp](S.B. リップマン 著)の7.2節
その後、ディレクトリを眺めましたが殆どが.cと.hであり、.cppはごく少数にとどまるので、どうやら基本的にCで書かれ、C++からも呼び出せるようになっているということなのかなと思います。
#検索できないので詳細を追うのは諦めました。
個人的には、そういう時はメソッドを分けてしまうな。
BOOL funcA(){ if(!funcB() ){ // エラー処理 return FALSE; } return TRUE;}
BOOL funcB(){ if (処理1が失敗) { return FALSE; } if (処理2が失敗) { return FALSE; } if (処理3が失敗) { return FALSE; } re
funcA()の後始末が別の関数になるのは抵抗あるなぁ。errorReport()が他所からも呼べる状態なのも。エラー処理はgoto使ってもfuncA()に入れておいたほうがカプセル化という点で優位な気が。
> 逐次処理なのにネストっぽくなってしまう。いったんは絶滅したかと思われた「逐次処理なのにネストっぽいコード」が、Promiseとなって現代に蘇った。救世主yieldの普及は遠い未来のことである…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
goto 使う派 (スコア:0)
たとえば3つの逐次処理があって、エラーなら次に進まないとすると、gotoなしだと
if (処理1が成功) {
if (処理2が成功) {
if (処理3が成功) {
}
}
}
となって逐次処理なのにネストっぽくなってしまう。
ホントの条件分岐やループがあったら取り返しの付かない深さに。
if (処理1が失敗) {
goto エラー終了
}
if (処理2が失敗) {
goto エラー終了
}
if (処理3が失敗) {
goto エラー終了
}
のほうがやりたいことがストレートに書ける気がするんだ。
実際、今回のコードもこんな感じ。
Re:goto 使う派 (スコア:2)
本来なら例外を使うべきところを、効率が求められるOS内コードなので goto で代用した、と考えると納得がいく気がします。
例外機能のありがたみがわかる事例 (スコア:1)
.cみたいなのでこのコードはC++ではなくCなのではないかと思います。
そうすると例外機能がないので。
自分で確認はしてないですが、コメントに「同じディレクトリに.cppのファイル」があるという話なようですね。
とすればプロジェクトは(恐らく)C++ も使える環境なんだろうと思うので
何故このコードがCでないといけないのか不思議には思いますが…。
C++である場合、例外の実装ではオーバーヘッドは主に投げる時に発生し、
投げない時には極力発生しないように工夫されているという話なので
チェックが失敗したときに少し遅くなる程度はそれほど問題にならない気もしなくはないです。
(失敗した場合、それよりうしろのチェックの処理時間はなくなるわけだし。)
参考: 「C++オブジェクトモデル―内部メカニズムの詳細 」 [amazon.co.jp](S.B. リップマン 著)の7.2節
Re:例外機能のありがたみがわかる事例 (スコア:1)
その後、ディレクトリを眺めましたが殆どが.cと.hであり、.cppはごく少数にとどまるので、
どうやら基本的にCで書かれ、C++からも呼び出せるようになっているということなのかなと思います。
#検索できないので詳細を追うのは諦めました。
Re: (スコア:0)
個人的には、そういう時はメソッドを分けてしまうな。
BOOL funcA()
{
if(!funcB() ){
// エラー処理
return FALSE;
}
return TRUE;
}
BOOL funcB()
{
if (処理1が失敗) {
return FALSE;
}
if (処理2が失敗) {
return FALSE;
}
if (処理3が失敗) {
return FALSE;
}
re
Re: (スコア:0)
funcA()の後始末が別の関数になるのは抵抗あるなぁ。
errorReport()が他所からも呼べる状態なのも。
エラー処理はgoto使ってもfuncA()に入れておいたほうがカプセル化という点で優位な気が。
Re: (スコア:0)
> 逐次処理なのにネストっぽくなってしまう。
いったんは絶滅したかと思われた「逐次処理なのにネストっぽいコード」が、Promiseとなって現代に蘇った。救世主yieldの普及は遠い未来のことである…。