[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 05/09 11:06 / Filesize : 125 KB / Number-of Response : 558
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

ぱっと見て「ヘタだなぁ」と思うコード その5



1 名前:デフォルトの名無しさん [2006/08/12(土) 01:56:11 ]
禁止ネタ(超既出)
・長い関数
・深いネスト
・グローバル変数
・goto
・memset
・malloc - free
・局所ブロック
・サンプルコードのtypo
・記述スタイル
・関数・変数名

過去スレ
その4: pc8.2ch.net/test/read.cgi/tech/1153312202/
その3: pc8.2ch.net/test/read.cgi/tech/1149986051/
その2: pc8.2ch.net/test/read.cgi/tech/1142741989/
初代 : pc8.2ch.net/test/read.cgi/tech/1141867015/


129 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 01:25:42 ]
ここで指摘の多い様な、ぱっと見の下手なコードって
C++に集中してる気がするのは気のせいか?

適当に書いても適当に通っちまったり、オペレーターオーバーロードとかで
出鱈目やってもコンパイラ的には全然OKだったり、無法がまかり通るからなのかな…

130 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 01:48:28 ]
Hoge::Hoge()
{
 this->isFuga = true;
}

よりも

Hoge:Hoge()
: this->isFuga(true)
{
}

が望ましい。


131 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 02:02:27 ]
なんで?プリミティブななんとかが関係有る?

132 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 02:05:00 ]
それ以前に何故にthisを明記するか。
voidは省略してやがる癖に。

133 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 02:07:57 ]
>>131
コンストラクタ本体での設定は、初期化じゃなくて代入になる。
constメンバとか、参照メンバはこの方法じゃないと初期化できない。

134 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 02:14:04 ]
>>133
まあ、普通に常識ではあるよな。
正直なところ基本型についてはどっちでやってもええやんとは思うが。
二重コンストラクタとか用意した方が取り回しの便利なクラスとかだと、
わざわざ無駄になる初期化部分を書くのが面倒ちい。

class Hage
{
int hige;
public:
Hage() { init(); }
void init() { hage = 0; }
};

とか。

135 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 05:08:27 ]
>>129
コードがキレイかどうかを気にするのがC++プログラマに多いからじゃね?

136 名前:118 mailto:sage [2006/08/22(火) 08:53:29 ]
>>120
わかりました、そうします。

>>121
まだちょっと実装不足です。

>>122
それがありました・・・orz

>>123
あれは実験コードで・・・今のもだけど

>>125
できるらしいです、Effective c++より

>>127
stringをマルチバイトでgetコマンドすると一バイトずつ読みバケるんで、
自分で処理するのにも自信ないのでc++のマルチバイト処理関数使ってます。
ちゃんと解説してる本やサイトなくてつらかった・・・

>>128
そういう方法で処理します。(enumハックでするとどうなるんだろう)

次にテンプレート化して提出します。え、そういうスレじゃない?

137 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 11:30:10 ]
Effective C++なんて読むレベルの奴がこんな指摘されるはず無いのだが



138 名前:デフォルトの名無しさん mailto:sage [2006/08/22(火) 14:24:07 ]
うーん、いや実際に読んでるよ。読むだけ

139 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 01:36:00 ]
MoreEffectiveもデザパタも読んでモヒカン入門した俺の頭のテカリ具合を見てくれ。
こいつをどう思う?

140 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 02:36:46 ]
すごく…氏ね…

141 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 07:19:15 ]
TYPOしたままやけくそで全部そのままTYPO名使ってるコード。
つーか置換しろよ…

142 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 08:54:23 ]
検索する時困るんだよな。
確か stopFlag だったよなーと思って探しても見つからず途方にくれる。
実は stopFlug でした、とか。そりゃみつからねーや。

143 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 10:49:14 ]
普通は見つからなかったらtypoだと思い"stop"で検索かける。

144 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 13:12:29 ]
stapFlugだったりとか。

ちょっと長めの名前だと、補完使ったりコピペするので、
TYPOにしばらく気づかないことが多いな。

145 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 13:23:18 ]
気付いたときには手遅れだったり。

146 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 13:25:49 ]
typoはtypeのtypoだ、とまことしやかに説明している人がいた。

147 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 13:34:16 ]
これまたリカーシブですね



148 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 20:46:08 ]
一応クラスでは作り終わった?評価よろしくお願いいたします

ttp://maidx.net/public_html/url.cgi?url=web.maidx.net/up/maru_077.zip&a=0

149 名前:デフォルトの名無しさん [2006/08/23(水) 20:46:52 ]
typoってどーゆーいみ?

150 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 20:52:07 BE:59908526-2BP(201)]
昔fj見てたとき、なんでふつーに日本語で書かないんだろって思ってたよ > typo

151 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 21:15:11 ]
typographical error

152 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 21:17:06 ]
>>148

・識別子が全部小文字で非常に見づらい。
単語の区切りが明確になるようにアンダーバーを入れれ。
ローカル変数も然り。

・getdateinputinfってのが何なのかさっぱりわからんけど適切な命名ではないと思う。

・getstreamopenでなくてis_stream_open。
名前だけ見ると別の意味になる。

・コメントがなさすぎ。命名の微妙さとあいまって何をやってるコードなのかさっぱりわからん。


153 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 21:28:33 ]
>>148
Error #503
Service Unavailable
BoostWeb BW4.2.16.1 Feb 24 2003 at bw03

154 名前:デフォルトの名無しさん mailto:sage [2006/08/23(水) 22:50:17 BE:404376899-2BP(201)]
>>148
>if(b){
>   value += a;
>}else{
>   value += a;
>}

これはバグ?


155 名前:デフォルトの名無しさん mailto:sage [2006/08/24(木) 12:28:27 ]
>>152
クラス名・変数名に迷ったら書き込むスレ。Part8
pc8.2ch.net/test/read.cgi/tech/1154448184/
ちょっと、行っています

>>153
即行消されたのか・・・

>>154
消し忘れです

一応やってみました
ttp://up2.viploader.net/mini/src/viploader63439.zip
バグありでファイルを開いてインプットした後
閉じてもう一回読んだときファイルストリームができない・・・なぜ?

156 名前:デフォルトの名無しさん mailto:sage [2006/08/25(金) 01:10:43 ]
>ファイルをとじらせるバグってる
日本語でOK。

157 名前:デフォルトの名無しさん [2006/08/28(月) 01:53:12 ]
開発で見かけた、T芝のコード。
関数の途中で数箇所return的な処理をする代わりにgoto使ってる。

void xxx()
{
:
if( ... )
{
goto END;
}

switdh( ... )
{
case xxx:
goto END;
:
}

END:
return;
}

・・・こういう目的限定なら使ってもいいのか?俺は使わないが。



158 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 02:09:36 ]
その例なら 普通に return した方が良い。

ただ、エラー処理が混じる場合は
goto を使った方がエレガントに書けるので
積極的に使えば良いという人も少なからずいる。
(goto排除原理主義者はこれを認めない。)

159 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 03:26:26 ]
別に下手でも何でもないような。
まあ、行数多い中でやってるなら、分けろよとは思うかもしれないけど。

goto排他原理主義者って、なんであんなに頑ななんだろうね。
どう見ても使った方がいいだろって状況でも
grepかけて突きつけてきたりするもんなー。

多重ループん中から抜ける時とか、同じ条件のifだだ並べにしてる方が
三億倍はキモいと思うんだが、何がそこまで彼らの憎しみを駆り立てるのか。

160 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 04:27:43 ]
なんでも極端にやるのはダメだよねぇ…
以前“短い関数”原理主義者を見かけたよ。
3行関数を大量生産したらかえって読みにくい。

161 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 05:52:50 ]
C言語ならありかもしれないな。

C++では例外やアルゴリズムやオーバーロードがあるから
gotoは完全にいらない子だけどね。

162 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 06:42:02 ]
アルゴリズムもオーバーロードも関係ないと思われ。
例外は確かにあるが、多重ループから抜けるのなんかに使ってたら、それこそヘタなコードだろ。
場合によっちゃJavaでだってバカにされるわ。

C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
使用を呑めない場合すらあるしなー。
Cで許されるのと同程度の使い方なら、C++で使ってたって何の問題もないと思うんだが。

163 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 07:09:16 ]
アルゴリズム類の適用で多重ループ自体の出番を減らせられるのは分かるが、
なんでもかんでもそれで書いてたら、それはそれで馬鹿なコードだな

case文のラベル名指しで飛んでるようなコードは流石に有害指定してもいいとは思うが、
ぱっと見すぐわかる範囲で簡潔に使われてる程度で目くじら立てるのは…

164 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 13:10:51 ]
よくあるのは、
:
:
return TRUE;
/* ↑ここまで正常系処理 */
error:
if (hoge) { hogeのリソースを解放; }
if (fuga) { fugaのリソースを解放; }
return ERROR;

みたいなやつ。hoge/fuga/...は一連の処理の最初にNULLで初期化しておく。

途中で処理が失敗したとき、どのリソースが割り当てずみかを気にせず、
末尾に飛べばいい。

165 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 13:11:41 ]
TRUE/ERRORってのは変な組み合わせだな。てきとーに読み替えplz

166 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:16:05 ]
>C++では例外やアルゴリズムやオーバーロードがあるから
なぜここにアルゴリズムが混じりますか??

167 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:35:00 ]
>>160
> 以前“短い関数”原理主義者を見かけたよ。

Kent Beckのことですね。



168 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:47:44 ]
>>164

正常系のリソース解放を一緒にすると下のようになるんだろうが、なんか微妙
なようなそうでないような。

result = SUCCESS;
goto end;
/* ↑ここまで正常系処理 */
error:
result = FAILURE;

end:
if (...)
if (...)
return result;

169 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 20:30:04 ]
>>162
なんでそんな例外を忌み嫌うのかよくわからん。

頭固いんじゃないの?

170 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:10:24 ]
>>162
> C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
必要なことをしているだけじゃないの?
例外を使わなくたって、デストラクタを呼ぶ必要がなくなるわけじゃないでしょ?

正常系の場合に(結果的に)無駄となることをする場合もあるけど、
例外を使うことによるメリットを考えれば普通は我慢できるはずだけど。


171 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:10:48 ]
>>169
え?多重ループから抜け出すのに例外使うの?

下手だなー。

172 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:54:37 ]
>>170
C++の例外処理は相当重たい処理だよ。
だからこそ例外を使わないというコンパイルオプションがあるくらいなのに。

173 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 00:26:04 ]
>>168
頻出なイディオムなのに簡潔に書けないもんだから
C++やその他の言語で try-catch が生まれたって流れなんでしょうね。
たまに C++ で書く時は finally 使えなくてムズムズする。
きちんとデストラクタ書けって話なんだけど。

174 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:03:40 ]
>>167
Kent Beckに限らず、Smalltalkerはn行を超えるメソッド(関数)が
ポコポコ出来るなんて信じられない、という発言を真顔でするね。

175 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 03:48:20 ]
多重ループじゃなくてイテレーションなら一発で抜けられるのにな

176 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 04:57:44 ]
goto信者が暴れていたようだな。
そんなに早さを求めたいのならC++なんて使うな。

177 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 05:05:42 ]
C++ではデストラクタ以外にリソース解放コードを書いてはいけない
よってgotoはいらない
逆にスコープアウト時の処理が書けないレガシーな言語には必要。
Javaはgotoがないのでご覧のとおり悲惨なことになっている



178 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 08:51:11 ]
ループを脱けるために例外を使うなんて、意味論的にも変だっつーの。

ところで、
LABEL:
 for(〜) {
  for(〜) {
   if (〜) break LABEL;
  }
 }

で、外側のforまで一気に break してくれる構文のある言語があったような木がするんだけど、なんだっけ?


179 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:01:15 ]
ラベル付きbreakはJavaにはあるな。C♯は goto ラベルか。
Perlだとbreakじゃなくてlastだが、これもラベルがつけられる。

Rubyだと
catch(:identifier) do
throw :identifier
end
と書く。 # これは例外処理ではない。

180 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:02:43 ]
D言語の言語仕様にはあったが実際どう動くかわからない

181 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 17:12:25 ]
>>177
関数内のある処理のために確保した一時メモリ領域とかもデストラクタで解放するの?
C♯のfinally構文に慣れたせいかいまいち理解できない。
具体的にどう書くの?



182 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:00:12 ]
>>181
つ std::auto_ptr
auto_ptrは腐ってるという意見もあるようだが。

183 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:10:39 ]
phpは break n; でn段のネストから抜ける

184 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:20:49 ]
「n段」ってのがPHPらしい仕様だよな

185 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:44:12 ]
>>182
ほへー。
それを徹底するくらいなら例外かgotoで終了処理したほうがよほどスマートだと思うんだけどな・・・

186 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:48:14 ]
>>182
auto_ptrはauto変数としてのみ使うもんだと思ってる。
移動コピーはcreate関数なんかに効率を落とさず対応するためのもので、
基本的にはコピーしない、と。

>>185
struct file {
FILE *f;
file(const char *path) { f = fopen(path, "r+"); }
~file() { fclose(f); }
};
int main()
{
file f("foo.txt");
// 何かする

} // close

187 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:08:06 ]
標準では未だにauto_arrayって入ってないんだっけ。
いや、自分で書いても一瞬だけどさ…。



188 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:14:53 ]
>>181
つ[More Effective C++]

189 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:01:50 ]
>>181
C#使いなら、System.IDispose.Disposeに書くようなことをC++ではデストラクタに書くと言えば通じるだろうか。
ただしusingに相当するものはなく、自動変数ならスコープを抜けるときに呼ばれるという感じ。

190 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:03:20 ]
すまん、IDisposableだったな。

>>186
auto_ptrを自動変数として使うだけなら、scoped_ptrでいいだろと思う俺。
今はまだBoostだから使用に抵抗を感じるのかもしれないけどね。

191 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:13:15 ]
boost馬鹿は死んでいいよ

192 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:53:53 ]
おまいが死んだら一番じゃん

193 名前:デフォルトの名無しさん [2006/08/31(木) 00:30:09 ]
try{

}
catch(Exception e){
 if(e instanceof HogeException){...}
}

もうね、アホカと。馬鹿かと。

194 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:36:44 ]
・飛んでくる例外の共通の親はException。
・各例外を捕まえたときの処理は同じだが結構分量アリ。
・捕まえずに上にそのまま通す例外もある
みたいな条件が重なったときは結構困るな。

195 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:42:10 ]
どういう場合にそういう状況に陥る?
設計しなおすと結構シンプルになったりしそうなんだが。

196 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:45:16 ]
・飛んでくる例外の共通の親はException。 →当たり前。
・各例外を捕まえたときの処理は同じだが結構分量アリ。 →メソッド化しろボケ。
・捕まえずに上にそのまま通す例外もある →catchしてthrowするか、何もするな。

どこがどう困るんじゃと。

197 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:48:57 ]
>>196
こいつ下手そう



198 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:05:51 ]
そうでもないよ

199 名前:デフォルトの名無しさん [2006/08/31(木) 01:12:26 ]
>>197
こう書いたらエエヤンっていってるだけなんだけど、だめ?

void exampleFunction()throws BarException{
 try{
  //FooException,BarException,BazExceptionが発生する可能性あり
 }
 catch(FooException e1){
  handleException();
 }
 catch(BarException e2){
  throw e2;
 }
 catch(BazException e3){
  handleException();
 }
}

200 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:24:53 ]
>>196
Exceptionまでさかのぼらないと共通の親クラスが見つからない、
だから、まとめて捕まえるならExceptionで捕まえるか、
別々に書くかしないといけない、ということだね。

201 名前:181 mailto:sage [2006/08/31(木) 05:10:40 ]
>>189
いや、C++も昔やってたからその辺のことはわかってるよ。
ただ一時メモリ領域もデストラクタで解放するっていうことに違和感を覚えただけ。


202 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 10:34:47 ]
BarException をcatchする意味がないじゃん。

handleException() は、handleException(e1) とかで多胎にするよーな?

203 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 13:59:45 ]
>>201
>一時メモリ領域
一瞬、スタック領域に取られたメモリの事かとおもた
じゃなかったら一時的かどうかはコンパイラには解らないから

204 名前:181 mailto:sage [2006/08/31(木) 15:12:31 ]
スタック領域だったらそもそも解放とか気にする必要がないのではw
まあとりあえず自分の話題については>>182で一応の解決を見たのでこれ以上の問答は無用です。


205 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 21:21:42 ]
例外も仕様の内だと思うんだけど。
なんでtry-catchなんて使うんだろうね。

ifとtryのどっちを使うのか明確にわけてあるプロジェクトにあたったことないな。

206 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:14:56 ]
>>205
こいつ下手そう

207 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:39:56 ]
>>206
おお!trycatchの適切な利用方法を説明してみてくれ。
なんかパっとしねぇの多いんだ。



208 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 23:30:19 ]
>>202
rethrow する前にログったり BarException 固有の処理するけど
紙面の都合で省かれてるんだと思うことにしよう。

> 多胎
派生例外クラスにありとあらゆるケースの例外処理が書かれて
かえって可読性が下がる気がしなくもない。

209 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:23:55 ]
当然のことだが、例外クラスはそれを使うクラスのことは知らない。
まさか、1クラスにつき1例外作るとか言うんじゃないだろうな。

210 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:34:41 ]
そう。だから例外処理で多態は困難に感じる。

211 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:40:22 ]
ここで「こいつ下手そう」発言君↓

212 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:42:04 ]
>>211
こいつ下手そう

213 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:45:06 ]
>>207
try {
resA->open(); // res: resource
resB->open();
resA->hoge();
resB->fuga();
resB->close();
resA->close();
}
catch () {
}

214 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:48:58 ]
んなーこたーない

215 名前:213 mailto:sage [2006/09/01(金) 00:52:06 ]
>>214
ん、俺?
俺いつもこうやってるよ。俺下手なのか?

216 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:52:40 ]
ここでもやっぱり「こいつ下手そう」発言君↓

217 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:53:34 ]
どう考えても213はおかしいだろ



218 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:53:42 ]
>>213
見るからに例外安全じゃないコードだな。
close前に例外飛んだらout

もしRAIIだから大丈夫だとしたら逆にcloseを明示的に書いているのがダサい。

219 名前:213 mailto:sage [2006/09/01(金) 00:54:12 ]
>>217
どこが?

220 名前:213 mailto:sage [2006/09/01(金) 00:55:14 ]
>>218
あー、俺やっぱり下手だわ。
意味さっぱりわかんね。

221 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 00:56:35 ]
>>218
エラーコードでいちいちエラーチェックするより、例外使ったほうがいいという例じゃないの?

222 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:00:20 ]
>208-210
派生例外クラスじゃなくて、handleException を多態にするという意味では?

void handleException ( Exception& e ); // 共通の処理
void handleException ( BarException& e ); // BarExceptionだけの処理

try{
 //FooException,BarException,BazExceptionが発生する可能性あり
}
catch( Exception e ){
 handleException( e );
}

223 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:07:01 ]
>>221
エラーチェックの話なら,
例外版は適切にRAIIとかfinally相当でリソースの後始末をするべき。
これだと例外を使うとリソースをリークするという話にしか見えん。

まともに例外を扱えないやつが例外を書くと危険極まりない。
下手糞の例外は下手糞のgotoよりはるかに凶悪

224 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:07:31 ]
>>220-221
resA の open に成功して、resB の open に成功した場合、
resA のリソースが開放されないので例外安全にならない。
スコープ抜けたら勝手に開放される(RAII)のであれば
わざわざ close 呼んでるのが冗長。

225 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:11:43 ]
>下手糞の例外は下手糞のgotoよりはるかに凶悪

まったくもってごもっとも。
つーか正直なところどんだけやってもC++の例外を使いこなす自信が持てん。

226 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:11:45 ]
>>224
たぶん主張内容から推察するに
× resBのopenに成功
○ resBのopenに失敗
だな。
主張内容は完全に同意。

227 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:16:58 ]
>>222
実際にやってみたか?引数のオーバロードは多態ではないから
e が BarException でも共通の処理のほうに飛ぶんだが。



228 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:17:16 ]
>>222
オブジェクト自身が振る舞いを知ってる場合が多態で
入り口(呼び出し側)でオーバーロード用意して
振り分けしちゃうのは多態とは言わないと思ってました。
実際のところどうなんでしょう?

>>226
ご指摘の通り。しかも223氏が本質的な発言先にしちゃってるし。
もう俺寝た方が良さそう。

229 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 01:23:53 ]
>>228
お休み、よい夢をー。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<125KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef