C++相談室 part33

■過去ログ置き場に戻る■ 1- 前250 次250 最新50

[memo] "9999999999_00.html#R20" という感じで、URLの最後に "#RレスNo" を追加すると幸せになれます。

C++相談室 part33

501 名前：main.cpp ：04/08/04 08:56: #include <exception>
#include <iostream>
#include "boost/timer.hpp"
void func_throws_exception();
void operation(int);
void try_in_loop(int counter_end)
{
  for (int counter = 0; counter < counter_end; ++counter)
  {
    try { func_throws_exception(); }
    catch (std::exception const& e) { operation(counter); }
  }
}
void try_outof_loop(int counter_end)
{
  int counter = 0;
CONTINUE:
  try { for (; counter < counter_end; ++counter) func_throws_exception(); }
  catch (std::exception const& e) { operation(counter); goto CONTINUE; }
}
int main()
{
  int const counter_end = 1000 * 1000 * 1000;
  boost::timer t;
  t.restart(); try_in_loop(counter_end); double const in_loop = t.elapsed();
  t.restart(); try_outof_loop(counter_end); double const outof_loop = t.elapsed();
  std::cout
    << "try_in_loop : " << in_loop << '\n'
    << "try_outof_loop: " << outof_loop << std::endl;
  return 0;
}
502 名前：sub.cpp ：04/08/04 08:56: void func_throws_exception(){}
void operation(int){}
503 名前：g++ (GCC) 3.3.1 (cygming special) ：04/08/04 09:01: $ g++ -O3 main.cpp sub.cpp && ./a.exe
try_in_loop : 20.329
try_outof_loop: 21.04
504 名前：デフォルトの名無しさん ：04/08/04 09:03: >>493だとスタックが死ぬので>>484がお勧め
>>501は論外
505 名前：デフォルトの名無しさん ：04/08/04 09:05: >>504
再帰は遅いしね
506 名前：501-503 ：04/08/04 09:07: gccならtryのオーバーヘッドはほとんど除去できている模様。
>>468が実測無しで「try {} catch() {} のオーバーヘッドの所為で」と言っている可能性もある。
507 名前：501-504 ：04/08/04 09:08: >>504
あれ？もしかして、なんか処理間違ってる？
508 名前：デフォルトの名無しさん ：04/08/04 09:09: >>506
gccならって時点で本題から外れてるじゃん。
try,catchのプロローグコードとエピローグコードが重い事を前提に議論してるんだし。
509 名前：501 ：04/08/04 09:19: あ、カウンタが進んでないな。 goto の前に ++counter; を入れないと処理が違う。

>>508
重い処理系での計測結果きぼん。
510 名前：デフォルトの名無しさん ：04/08/04 09:37: Borland C++ 5.6.4(BCB6)
bcc32 -O2
try_in_loop : 31.55
try_outof_loop: 14.62
511 名前：デフォルトの名無しさん ：04/08/04 09:40: 少なくともC++では、例外に関しては実行速度は全く考慮されていないからなあ。
512 名前：デフォルトの名無しさん ：04/08/04 09:47: >>510
もっと重い処理系も多そうだね
513 名前：デフォルトの名無しさん ：04/08/04 09:49: VC++7.1
cl -O2
try_in_loop : 0
try_outof_loop: 0

やっぱVC++の最適化は格が違うね
514 名前：デフォルトの名無しさん ：04/08/04 09:59: >>513
別ファイルに分けても消されるのか？すげえな。

sub.cpp を以下に変更して追試してみてほしい。
volatile int n;
void func_throws_exception(){++n;}
void operation(int){n=0;}
515 名前：デフォルトの名無しさん ：04/08/04 10:08: >>514
それじゃ throw() と解釈されるかもしれないから、
void func_throws_exception(){++n;if(n<0)throw n;}
くらい入れといたほうがいいかも。
516 名前：デフォルトの名無しさん ：04/08/04 10:08: >>514
try_in_loop : 0.43
try_outof_loop: 0.441
517 名前：515 ：04/08/04 10:10: catch(std::exception const&) だから、throw std::exception() にしないといけないな。
518 名前：デフォルトの名無しさん ：04/08/04 10:19: VC++7.1
cl -O2 -GX
一応さっきのも-GXは全部付けてるんで

try_in_loop : 13.669
try_outof_loop: 14.751
try_outof_loop2: 8.597

void func_throws_exception()
{
static int i=0;
if(++i % 4096 == 0)
throw std::exception();
}

void try_outof_loop2(int counter_end)
{
int counter = 0;
while(counter < counter_end)
{
try { for (; counter < counter_end; ++counter) func_throws_exception(); }
catch (std::exception const& e) { operation(counter); ++counter; }
}
}
519 名前：デフォルトの名無しさん ：04/08/04 11:25: >>518
その try_outof_loop2 を参考にして、以下のようなものを思いついた。
void loop_in_try(int counter_end)
{
  for (int counter = 0; counter < counter_end; ++counter)
  {
    // ループ内での try によるオーバーヘッドを軽減するため、 try の中でも同じ条件でループします
    try { do func_throws_exception(); while (++counter < counter_end); break; }
    catch (std::exception const& e) { operation(counter); }
  }
}

オリジナル(try_in_loop)からの変更箇所も少なく、見た目のキモさをフォローするコメント付き。
>>468への答えとしてはこれが適切と思う。
520 名前：デフォルトの名無しさん ：04/08/04 11:42: >>505
今回のケースだと>>484の方が遅いはず
521 名前：デフォルトの名無しさん ：04/08/04 11:57: std::nth_element(vec.begin(), vec.begin(), vec.end(), HogeComparator());
最も条件に適合する要素を先頭に持ってくるコードですが、
これより良い方法はありますか？
あったら教えて下さい。
522 名前：デフォルトの名無しさん ：04/08/04 12:01: 何かを勘違いしちゃってるな
523 名前：デフォルトの名無しさん ：04/08/04 12:12: とりあえず
std::partial_sort(vec.begin(), vec.begin(), vec.end(), HogeComparator());
よりはnth_elementの方が速いと思うのですが。
先頭に来て欲しい要素が1個なので結果は同じですよね？
524 名前：デフォルトの名無しさん ：04/08/04 12:49: >>523
定義だと、nth番目を境に[first,nth)のどの要素も[nth,last)より小さくなるように並び替えるってことなので、
vec.begin(), vec.begin() はダメでしょう（特定の実装でどうなってるかは知りません）。

サイズが1以上かどうかを確かめた上で、
std::nth_element(vec.begin(), vec.begin()+1, vec.end(), HogeComparator());
の方が良いと思う。
525 名前：524 ：04/08/04 12:50: あ、ごめん。ダメじゃないかも。
526 名前：デフォルトの名無しさん ：04/08/04 13:21: >>489
まじかよ。
MFCのCFileでファイルクラスの例外スローに苦しめられた経験があるもんで、
.NETでも例外スローするってのは正直ひくね。
ファイル操作のような、アプリ依存の分岐処理が必須になる分野に
例外機構が向いているかどうか疑問だ。
527 名前：デフォルトの名無しさん ：04/08/04 13:26: >>405
gotoもそうだし、ダウンキャストしまくりでびびったよ
ゲームだからいいのかね
528 名前：デフォルトの名無しさん ：04/08/04 13:38: C++の落とし穴とは、普通はどういう物を指しますか？
オブジェクトコピーによってデストラクタが二度呼び出されたり、
ポインタ位置破壊を行ってしまうような事を指すんでしょうか？
529 名前：デフォルトの名無しさん ：04/08/04 13:48: >>521
std::swap(*std::max_element(vec.begin(), vec.end(), HogeComparator()), vec.front());
ではどう？
530 名前：デフォルトの名無しさん ：04/08/04 14:17: >>527
ハンガリアンも使いまくり
531 名前：デフォルトの名無しさん ：04/08/04 14:24: >>526
へぇ。

私の場合、標準の fstream 関係がデフォルトでは例外を投げないことの方が気持ち悪いです。
ファイル関連こそ、例外を使った方が楽だと思うんだけど。
532 名前：デフォルトの名無しさん ：04/08/04 14:42: >>527
ゲームとか関係ないかと…
単にスタイルの問題？
533 名前：デフォルトの名無しさん ：04/08/04 14:50: ＞527
やる着なかったんだよ．
534 名前：デフォルトの名無しさん ：04/08/04 15:44: >>532
ゲーム＞速度重視＞実行時型チェックなんかしてられるか(ノ `Д´)ノミ _I___I_
じゃない？
535 名前：デフォルトの名無しさん ：04/08/04 15:46: C++を基礎から勉強しています。
質問なのですが、
http://wisdom.sakura.ne.jp/programming/cpp/cpp12.html
このページにある"オブジェクトを返す"のサンプルでは、関数内で定義した
オブジェクトを関数の返り値として返しています。
これは、
http://www.cmagazine.jp/src/kinjite/c/variable.html#index17
【自動変数をポイントして，それを関数の戻り値にする】
に該当するのではないでしょうか？これはC++ではやっても良い事なのですか？
よろしくお願いします。
536 名前：デフォルトの名無しさん ：04/08/04 15:47: >>531
釣り？

自分のエラー処理（任意）とクラス例外処理（強制）で2度手間。
ファイルの例外を楽と思うヤシの気が知れんね。経験浅いの？
537 名前：535 ：04/08/04 15:50: 関数内で定義→関数内で宣言、でした。
538 名前：デフォルトの名無しさん ：04/08/04 15:52: >>534
でも dynamic_cast は…

ひょっとしたら、HDR がどうとか、そういうアルゴリズムを他の事に
気が紛らわされることなく理解してもらためにやってるのかも…
539 名前：デフォルトの名無しさん ：04/08/04 15:53: >>535
> 戻り値として生成したオブジェクトの複製を返して終了します
複製を返しているので
>【自動変数をポイントして，それを関数の戻り値にする】
には当たりません．該当するのは以下のような場合です．
Kitty *getKitty(char *str) {
Kitty *obj (new Kitty ());
obj->str = str;
return obj;
}
540 名前：539 ：04/08/04 15:55: >>539
ボケけてた．該当するのは，
Kitty *getKitty(char *str) {
Kitty obj Kitty ())
obj.str = str;
return &obj;
}
です．
541 名前：デフォルトの名無しさん ：04/08/04 15:55: >>530
つーか元祖ハンガリアン勤務先なので　ﾄﾞｿﾞｰ（ ´∀｀）つ
542 名前：デフォルトの名無しさん ：04/08/04 15:55: >>535
int func()
{
int a = 1;
return a;
}

と同じこと。
戻り値として返されるのは関数内の自動変数をコピーしたもの。
543 名前：デフォルトの名無しさん ：04/08/04 15:56: ローカルの参照やポインタを返すなってことさ
544 名前：デフォルトの名無しさん ：04/08/04 15:57: >>535
C-Magazineが間違っているだけ。
545 名前：539 ：04/08/04 15:57: 何度もすんません．540は
- Kitty obj Kitty ())
+ Kitty obj;
に訂正致します．
546 名前：デフォルトの名無しさん ：04/08/04 16:05: どうでもいいけど>>535のリンク先
while(NULL != thePtr){
ってやってる。宗教健在かぁ。
547 名前：デフォルトの名無しさん ：04/08/04 16:06: 害の無い宗教は放置。
548 名前：535 ：04/08/04 16:11: 解説ありがとうございます。return時に指定された変数(や定数)を
スタックにコピーした上でretするということなのでしょうか。
何にしてもC・C++に関係なく自分が勘違いしていたようです。
-S出力したりしてもう少し勉強しようと思います。
549 名前：デフォルトの名無しさん ：04/08/04 16:11: >>547
見難いだろ。
550 名前：デフォルトの名無しさん ：04/08/04 16:11: >>547
その通り。
変数・定数の頭文字を大文字にされた日にゃ、困るけど。
551 名前：デフォルトの名無しさん ：04/08/04 16:17: >>536
うーん。経験浅いのかも。計算系が主だし。
自分のエラー処理とクラスの例外処理を「まとめて」扱えるから楽かなと思って。

今は、

std::ifstream ifs(filename);
if (!ifs)
　　throw Hoge();

とかやってる。そうすると catch を一カ所にまとめてかけて楽だし。
ヘボい？どうやるのがかっこいいのかな？
552 名前：デフォルトの名無しさん ：04/08/04 16:30: >>551
自分の投げたいときだけ投げるわけじゃねーだろ、ライブラリの例外クラス。
お前の書いたサンプルは、任意使用の例外処理だろが。
経験が浅いだけでなく、日本語も不自由なのか？
553 名前：デフォルトの名無しさん ：04/08/04 16:35: >>552
>>551は強制処理の例外をstd::ifstreamが投げないから仕方無く任意処理の例外を書いてるんじゃないのか？
554 名前：553 ：04/08/04 16:35: 任意処理->任意使用
555 名前：デフォルトの名無しさん ：04/08/04 16:40: >>553
自分でthrowしている時点で、論点が違うでしょ。
今問題にしているのは、クラス内部から勝手にthrowするファイルクラスの利便性について。
556 名前：デフォルトの名無しさん ：04/08/04 16:51: >>552
ごめん。日本語が不自由なのは認めるけど、言いたいのは >>553 がフォローしてくれた通り。
「クラス内部から勝手に」ってのが、よくわからないけど……。
普通、例外ってメソッドから勝手に投げられてくるものじゃないの？
557 名前：デフォルトの名無しさん ：04/08/04 17:00: おまいらー。はなしがかみあってないぞー。
558 名前：デフォルトの名無しさん ：04/08/04 17:10: >>556
とりあえず、メソッドから直接投げられると困ることがあるってことに気付けよ。

計算系って、大学か？
どうせ、exit()乱用するアフォプログラム書いてんだろ？
559 名前：デフォルトの名無しさん ：04/08/04 17:12: >メソッドから直接投げられると困る
std::bad_alloc投げない化石コンパイラでも使ってて下さい
560 名前：デフォルトの名無しさん ：04/08/04 17:15: >>558
そのための例外だろ？
561 名前：531=551=556 ：04/08/04 17:23: >>556

え？すみません。全然わからなくなってしまいました。

「メソッドから直接投げられると困ることがある」ことに、どうしても気づけません。
私の主張（というほどじゃないけど）「メソッドから直接例外を投げてくれないと面倒くさい。」です。

556さんじゃなくても構いませんので、556さんがどういうことを言いたいのか解説してもらえませんか？
日本語不自由ですみません……orz
562 名前：デフォルトの名無しさん ：04/08/04 17:24: >>561
すみません。556は自分でした。558さんですね。
563 名前：デフォルトの名無しさん ：04/08/04 17:25: 例外処理に関して知った風なこと言ってるヤシ、
「自分で作った」例外を投げるクラスぐらいしか使ってないだろ。
完全に自己満足の世界といっていい。

他人に使われることを想定してクラスを作ったら、
クラス内部からスローするような仕様は下の下だということに気付けるはずだ。
564 名前：デフォルトの名無しさん ：04/08/04 17:26: >>563
俺も、こいつが何を言いたいのかさっぱりわからん。
newを使うな、ってことを言いたいのか？
565 名前：デフォルトの名無しさん ：04/08/04 17:28: C++ で new を使わないのはある意味尊敬するなｗ
566 名前：デフォルトの名無しさん ：04/08/04 17:29: >>563
主張は分かったから、良かったら根拠を挙げて紅か？
567 名前：デフォルトの名無しさん ：04/08/04 17:29: >>563
568 名前：デフォルトの名無しさん ：04/08/04 17:29: 関数から例外を投げないほうがいいと言っている人は
ライブラリは戻り値でエラーかどうかを毎回返したほうが良い
と言っているのですか？
569 名前：デフォルトの名無しさん ：04/08/04 17:30: newどころかSTL全般が駄目なのでは。
570 名前：デフォルトの名無しさん ：04/08/04 17:30: 何のためのC++なんだろうな(w
571 名前：デフォルトの名無しさん ：04/08/04 17:31: >>563
心から同意
誰か意地になってるやつがいるだけの気がする

実際は作るときより、使うとき困るんだがな
572 名前：デフォルトの名無しさん ：04/08/04 17:31: 昔の人は偉いよね。例外なんかなくてもちゃんと作ってたんだから。
今同じことしようとするとめんどくさくて仕方ない。
573 名前：デフォルトの名無しさん ：04/08/04 17:31: つーかクラス内部ってどこだよ。
574 名前：デフォルトの名無しさん ：04/08/04 17:32: >>563はきっと大域newオーバーロードしてあるし、
STLは全部自分で書いてる。
575 名前：デフォルトの名無しさん ：04/08/04 17:33: いくらなんでも一気にこれだけレスが憑くのはありえないな…
576 名前：デフォルトの名無しさん ：04/08/04 17:33: 563 == 571 ？

どっちでもいいから
早く具体例を挙げろ
577 名前：デフォルトの名無しさん ：04/08/04 17:33: 発生したエラーが致命的かどうか判断するのは、
クラス利用者であってクラス作成者ではない。

クラスに例外処理を実装して得意気になる馬鹿はPGをやめた方がいい。
578 名前：デフォルトの名無しさん ：04/08/04 17:34: >>563は例外安全
579 名前：デフォルトの名無しさん ：04/08/04 17:34: >>577
是非C++標準委員会のSTL策定したメンバーの方々のメールでも送りつけて下さい
580 名前：デフォルトの名無しさん ：04/08/04 17:35: >>563はthrow()の男
581 名前：デフォルトの名無しさん ：04/08/04 17:36: 564から自演の嵐
582 名前：デフォルトの名無しさん ：04/08/04 17:38: 例外投げられても、それが致命的じゃないなら
catchして処理して正常系に戻ればいいのではないのか？
583 名前：デフォルトの名無しさん ：04/08/04 17:38: >>563はtry,catch構文の書き方が分からない
584 名前：デフォルトの名無しさん ：04/08/04 17:39: >>577
別に致命的じゃなくても例外投げて良いと思うぞ。
要は、処理を続行できない事態が発生した時に投げれば良い。

致命的かどうか判断するのは>>577の言うように利用者だから、
tryの位置やcatchの内容にそれを反映させる。
585 名前：デフォルトの名無しさん ：04/08/04 17:40: >>563の戻り値はいつもint
586 名前：デフォルトの名無しさん ：04/08/04 17:41: >>563はGetLastErrorマニア
587 名前：デフォルトの名無しさん ：04/08/04 17:42: 自演もうざいが、煽りもうざい。
議論に参加しない奴は黙ってろ。
588 名前：デフォルトの名無しさん ：04/08/04 17:43: 低レベルすぎるのでageときますね
589 名前：デフォルトの名無しさん ：04/08/04 17:44: >>563さんがどうやってエラーを返してるのか知りたいです。
やっぱ返り値は全部intかenumですか？
それともエラーの時はNULLとか返してGetLastError機構を用意するのですか？
590 名前：デフォルトの名無しさん ：04/08/04 17:45: スレ立てて他でやれ

>>587
煽りが自演だろ
591 名前：デフォルトの名無しさん ：04/08/04 17:47: >>589
は！ひょっとして >>563 の方が釣りなのか。そんな餌に...ｸﾏｰ
592 名前：デフォルトの名無しさん ：04/08/04 17:47: >>576
とりあえず、MFCのCFileやCInternetSessionなどを使ってプログラムを組め。
CException系例外クラスをキャッチするプログラムだ。

サンプルを示したところで、それはちゃんと動くし動作確認されたものだ。
それでは煩雑さを説明したことにならない。わかるだろ？
MS様の作った仕様を逐一追いかける意味で、自力でサンプルプログラムを組め。
いかにクラスの例外スロー機構が煩わしいかが実体験できる。
593 名前：デフォルトの名無しさん ：04/08/04 17:48: >>563==592さん
>>589
594 名前：デフォルトの名無しさん ：04/08/04 17:50: どう煩わしくなったかは教えてくれないのね。
595 名前：デフォルトの名無しさん ：04/08/04 17:50: >>591
気づいてしまったね。うまくやられたっぽいよね。
596 名前：デフォルトの名無しさん ：04/08/04 17:51: >>563さんは自分でクラス書いた事無いんですか？
597 名前：デフォルトの名無しさん ：04/08/04 17:52: >>584
＞tryの位置やcatchの内容にそれを反映させる。

多くの場合、スコープがcatchに移動していて、エラーの原因となったデータは消滅している。
エラー番号が判る程度では、役不足だった経験はあるだろ？
598 名前：デフォルトの名無しさん ：04/08/04 17:52: 例外禁止だとRAIIが達成できないな。
無効状態のオブジェクトを作りたくないときどーすんだ？
599 名前：デフォルトの名無しさん ：04/08/04 17:54: >>563==597さん
例外ならエラー番号以上の事が分かりますよ。
600 名前：デフォルトの名無しさん ：04/08/04 17:54: このスレは以後>>597の役不足につっこむスレとなります
601 名前：デフォルトの名無しさん ：04/08/04 17:54: 一体何人が>>563を演じているんだ
602 名前：デフォルトの名無しさん ：04/08/04 17:56: >>601
563は一人だろ
粘着が自演
603 名前：デフォルトの名無しさん ：04/08/04 17:58: >>563は結局何が言いたいのか分からないのですが。
結局tryとかcatch書くのが面倒なだけなんですか？
604 名前：デフォルトの名無しさん ：04/08/04 17:59: >>597
消滅させるかどうか選ぶのはtry/catchを書いたプログラマ自身じゃないか？
投げられた例外について多くを知りたければ
呼び出しの深いところで(throwに近いところで)catchすればいい。
605 名前：デフォルトの名無しさん ：04/08/04 18:00: >>599
サンプルを示して。
606 名前：デフォルトの名無しさん ：04/08/04 18:00: 例外はエラー以外には使うな、という考えでもないんだよな。
主張がよくわかんね。
607 名前：デフォルトの名無しさん ：04/08/04 18:00: >>597
そのために例外クラスを作るんじゃないの？
自作クラスでは、全部 exception とか投げてるから
そーいうことで困るんだとおもうよ。
608 名前：デフォルトの名無しさん ：04/08/04 18:00: >>605
std::exception

と、563のまねをしてみるテスト。
609 名前：デフォルトの名無しさん ：04/08/04 18:00: >>563は例外クラスを定義しているライブラリは使いません。
IndyとかMFCとかSTLとかboostとか。
610 名前：デフォルトの名無しさん ：04/08/04 18:01: 例外が駄目だということなのですが、
どうするのが良いスタイルなのかを示してくれたほうが嬉しいです。
自分が提供するライブラリクラスで例外使用を禁じられた場合
1. 関数からintやenumの戻り値を返す。
2. エラー情報格納部を用意してGetLastErrorのようなことをする。
のような解決を試みると思います。
1や2のようにしているのか、それとももっと良い方法なのか
示していただけ無いでしょうか。
611 名前：デフォルトの名無しさん ：04/08/04 18:02: >>605
サンプルも何も、
例外クラス定義してエラー番号以上の情報を入れるだけなんですけど…
612 名前：デフォルトの名無しさん ：04/08/04 18:03: >>604
信者の詭弁ですよ。

×呼び出しの深いところで(throwに近いところで)catchすればいい。
○呼び出しの深いところで(throwに近いところで)catchしなければならない。
613 名前：デフォルトの名無しさん ：04/08/04 18:03: もういいんじゃない。
>>563は例外クラスが分かってないでFAで。
スレの無駄。
614 名前：デフォルトの名無しさん ：04/08/04 18:03: >>604
恐らくライブラリ関数内で作られたようなオブジェクトの情報を
取得できないことを指摘しているのだと思う。

ライブラリ作成者側が気を使ってくれるなら、
例外クラスの中にその情報を入れてくれるんだけどね。
615 名前：デフォルトの名無しさん ：04/08/04 18:05: ＞ライブラリ関数内で作られたようなオブジェクトの情報を取得
良く意味分からないんですけど、例外じゃくて戻り値ベースだと
それが分かるんですか？
そもそもライブラリ関数内で作られたようなオブジェクトの情報を取得するのは
カプセル化と相反していませんか？
616 名前：デフォルトの名無しさん ：04/08/04 18:05: ちょっと相互リンクしておきますね。
http://pc5.2ch.net/test/read.cgi/tech/1068302657/
617 名前：デフォルトの名無しさん ：04/08/04 18:06: >>563はここで勉強してきたら？
例外処理exception, runtime_errorの使い方
http://pc5.2ch.net/test/read.cgi/tech/1051690231/
618 名前：デフォルトの名無しさん ：04/08/04 18:08: >>617
そこの8=468
619 名前：デフォルトの名無しさん ：04/08/04 18:08: >>563のようなバカにエラー処理を強制させる意味でも例外を使うべきだ。
>>563は戻り値ベースだったら戻り値なんてチェックしないだろう。間違いない。
もっとも>>563のようなヴァカは全部tryで囲んでcatch(...){}で終わりだろうけど。
620 名前：デフォルトの名無しさん ：04/08/04 18:09: >>615
いや、俺も例外推奨派なので、戻り値ベースだとできるとか
そういう意味の発言はしていないよ。>>614にもそうは書いてないよね。
必要な情報を入れてくれていない「例外を投げる側の不備」が
あることもあるよねって話。

ライブラリ関数内で一時的に生成されて
関数内で一生を終えるような情報を例外クラスに入れて投げるのって
カプセル化に反するの？別にメンバ変数の内容を公開するわけじゃないよ。
621 名前：デフォルトの名無しさん ：04/08/04 18:12: >>610
それで十分。
622 名前：デフォルトの名無しさん ：04/08/04 18:15: >>619
逆だな。
戻り値を厳密にチェックしてエラー時の処理を細かく制御したい場合、強制スローは迷惑。
623 名前：デフォルトの名無しさん ：04/08/04 18:16: >>621
なるほど。じゃぁ何かするたびにif文でその処理が成功したかどうかを
逐一チェックしろと言われているのですね。了解。
624 名前：デフォルトの名無しさん ：04/08/04 18:17: >>620
いまいち何が言いたいのか分かりませんが、
ライブラリ作成者側はエラーの詳細を伝えるべきではありますが、
内部で使うオブジェクトの詳細を与えるべきだとは思えません。
本来利用者側かでは知る必要がない、
内部で使うローカルオブジェクトの実装の詳細を知る必要が出てくるので。
625 名前：デフォルトの名無しさん ：04/08/04 18:18: >>624
オブジェクトの詳細じゃなくて、エラーや例外の詳細だと思う。
626 名前：デフォルトの名無しさん ：04/08/04 18:19: >>622
(ﾟДﾟ)ﾊｧ?
例外クラスは一種類だけではありませんし、
例外クラスの中にも情報を入れる事が出来るのですよ。
627 名前：デフォルトの名無しさん ：04/08/04 18:21: アンチを相手にするのは時間の無駄だろ。
アホを啓蒙してやりたいって事なら話は別だが。
628 名前：デフォルトの名無しさん ：04/08/04 18:21: つーかさ、何で話がすり変わってるの？
MFCが吐くCFileのExceptionクラスとやらは詳しい情報吐いてくれないのかも知れないけど、
自分で例外クラス作ればいくらでも詳しい情報書けるぜ。
それなのに自分でクラス書く時に例外吐くなとはどういう事よ？
>>563出てこいよコラ
629 名前：デフォルトの名無しさん ：04/08/04 18:23: ぶっちゃけ、このスレには何人いるんだろうか。
630 名前：デフォルトの名無しさん ：04/08/04 18:23: とりあえず初めの>>563はもういない気がする。
己の無知に気づいて。
631 名前：デフォルトの名無しさん ：04/08/04 18:25: >>623
逐一チェックしろ。
いざ、エラー発生位置などのダンプ情報が欲しくなった時、
手に負えないのが、クラスの例外スロー。
632 名前：デフォルトの名無しさん ：04/08/04 18:25: そんな事より人に使わせるクラスに
例外仕様も書かない輩が嫌いだ。
633 名前：デフォルトの名無しさん ：04/08/04 18:26: >>563は正しいでしょ。
マジで馬鹿だよ、クラスから例外吐くヤシ。
634 名前：デフォルトの名無しさん ：04/08/04 18:26: >>631
エラー発生位置を例外クラスに詰める事も出来るし、
そもそもデバッガってご存じ？
635 名前：デフォルトの名無しさん ：04/08/04 18:27: >>632
>>580
636 名前：デフォルトの名無しさん ：04/08/04 18:27: 議論云々の前に例外を知らなすぎる
637 名前：612 ：04/08/04 18:28: >>628
信者の詭弁ですよ。

×自分で例外クラス作ればいくらでも詳しい情報書けるぜ。
○自分で例外クラス作らないと詳しい情報書けないぜ。
638 名前：デフォルトの名無しさん ：04/08/04 18:29: >>624
こんな例を出すのが適当かどうかわから無いけど例を出す。
ある仕様のXMLファイルのストリームを受け取って、
必要な情報を返すようなライブラリ関数があったとしよう。
（ライブラリの実装としてはそのXML情報をDOMとして取り出して処理しているとする）

DOMツリー構築後、処理途中で与えられたXMLが仕様と合っていない
不備があったとして、どこが不備なのか返すために
Nodeオブジェクトを例外クラスに格納して返したいと思わない？
Nodeオブジェクトがあればどこが仕様に合っていなかったのか
すぐわかると思うけど。

これが無いと、ユーザにXMLのどこが間違っているか示してあげることも
できないんじゃないかな。
639 名前：デフォルトの名無しさん ：04/08/04 18:30: >>637
そもそもstd::exceptionを直接吐く事の方が少ないと思うのですが、
詭弁ですか？そうですか。
640 名前：デフォルトの名無しさん ：04/08/04 18:31: >>634は、クラス使用者に強要される制限が理解できていない。
>>634は、デバッガが動く環境でしか開発したことがない。
641 名前：デフォルトの名無しさん ：04/08/04 18:32: >>638
そもそもそのライブラリを使うのに
Nodeオブジェクトの実装を知っている必要がある
(メソッドにNodeを渡したりメソッドからNodeが帰ってきたりする)
のであればそれは構わないのでは無いかと。
642 名前：デフォルトの名無しさん ：04/08/04 18:32: 例外を使う/使わないは純粋に記述量にしか影響しない。
多くの場合、戻り値主義で完璧にやろうとすると複雑さが許容範囲を越える。
643 名前：デフォルトの名無しさん ：04/08/04 18:33: >>563が返す例外はいつもint
644 名前：デフォルトの名無しさん ：04/08/04 18:33: >>618
ファイルのエラーはシーンチェンジと同列ってことですか
645 名前：デフォルトの名無しさん ：04/08/04 18:34: .NET Framework クラスライブラリ
FileStream コンストラクタ (String, FileMode, FileAccess)
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemiofilestreamclassctortopic4.asp

例外
例外の種類条件
ArgumentNullException path が null 参照 (Visual Basic では Nothing) です。
ArgumentException path が空の文字列 ("") か、空白しか含んでいないか、無効な文字を 1 つ以上含んでいます。
FileNotFoundException ファイルが見つかりません。たとえば、 mode が FileMode.Truncate または FileMode.Open の場合に、 path で指定されたファイルが存在しません。これらのモードでは、ファイルが既に存在している必要があります。
IOException FileMode.CreateNew が指定されているのに、 path で指定したファイルが既に存在していることなどが原因で I/O エラーが発生しました。
SecurityException 呼び出し元に、必要なアクセス許可がありません。
DirectoryNotFoundException 割り当てられていないドライブであるなど、指定されたパスが無効です。
UnauthorizedAccessException access が Write または ReadWrite であるのに、ファイルまたはディレクトリが読み取り専用に設定されているなど、指定した path に対する access 要求がオペレーティングシステムで許可されません。
PathTooLongException 指定したパス、ファイル名、またはその両方がシステム定義の最大長を超えています。たとえば、Windows ベースのプラットフォームの場合、パスの長さは 248 文字未満、ファイル名の長さは 260 文字未満である必要があります。
ArgumentOutOfRangeException mode に無効な値が含まれています。
646 名前：デフォルトの名無しさん ：04/08/04 18:35: >>640
>クラス使用者に強要される制限
で、それは何？
647 名前：デフォルトの名無しさん ：04/08/04 18:35: >>645
そもそも.NETは純粋なC++では動きません。ManagedC++。
648 名前：デフォルトの名無しさん ：04/08/04 18:36: >>563は神
649 名前：デフォルトの名無しさん ：04/08/04 18:37: >>647
無知なお前らにまともなクラスライブラリの仕様を教えてやったんだよ。
650 名前：デフォルトの名無しさん ：04/08/04 18:38: >>641
ライブラリ使用者側が知っている情報レベルのものなら
例外クラスに入れても良いという考え方だということか。納得できる。

じゃぁ、もしライブラリ使用者側がNodeオブジェクトについて
知らない場合、君ならどうやって例外情報を構築するのか示して欲しい。
俺としてはそれができるならそうしたいのだし。
651 名前：563 ：04/08/04 18:38: やっぱ、夏休みでノンプロが多いな・・・。

一応いっとくけど、漏れは例外処理そのものは肯定する。
特に、エンドPGが>>551のサンプルのように自分で自作クラスをスローするのは賛成だ。
糞なのはクラスの例外throw。支持する馬鹿、氏ね、マジで。
652 名前：デフォルトの名無しさん ：04/08/04 18:38: 何かさあ>>563の頭の中には何か意見があるんだろうけどさあ、
それを書いてくれないとこっちは分からないんだよね。
漏れは例外は嫌いだしか伝わってこないんだもん。
実生活でも話すの苦手なのかな？
653 名前：デフォルトの名無しさん ：04/08/04 18:38: >>646
try節を書く必要がある、という制約 (ﾌﾟｹﾞ
654 名前：デフォルトの名無しさん ：04/08/04 18:39: >>647
例外を適用するコンテキストは言語には依存しないだろう。
655 名前：デフォルトの名無しさん ：04/08/04 18:40: >>650
そういう場合はassertだろう。
656 名前：デフォルトの名無しさん ：04/08/04 18:40: 563 名前：デフォルトの名無しさん[sage] 投稿日：04/08/04 17:25
例外処理に関して知った風なこと言ってるヤシ、
「自分で作った」例外を投げるクラスぐらいしか使ってないだろ。
完全に自己満足の世界といっていい。

他人に使われることを想定してクラスを作ったら、
クラス内部からスローするような仕様は下の下だということに気付けるはずだ。

563 名前：デフォルトの名無しさん[sage] 投稿日：04/08/04 17:25
例外処理に関して知った風なこと言ってるヤシ、
「自分で作った」例外を投げるクラスぐらいしか使ってないだろ。
完全に自己満足の世界といっていい。

他人に使われることを想定してクラスを作ったら、
クラス内部からスローするような仕様は下の下だということに気付けるはずだ。

563 名前：デフォルトの名無しさん[sage] 投稿日：04/08/04 17:25
例外処理に関して知った風なこと言ってるヤシ、
「自分で作った」例外を投げるクラスぐらいしか使ってないだろ。
完全に自己満足の世界といっていい。

他人に使われることを想定してクラスを作ったら、
クラス内部からスローするような仕様は下の下だということに気付けるはずだ。
657 名前：デフォルトの名無しさん ：04/08/04 18:41: >>563

>他人に使われることを想定してクラスを作ったら、
>クラス内部からスローするような仕様は下の下だということに気付けるはずだ。

この部分はどう説明なさるのですか？
658 名前：デフォルトの名無しさん ：04/08/04 18:43: >>651
それで結局どうして糞なんですか？
659 名前：563 ：04/08/04 18:43: >>652
一応PGを飯の種にしてるから、核心の部分はぼかさせてもらう。
例外が嫌いなのは悪い事じゃないと思う。
むしろ、C++の固有機能を必死に使おうとする馬鹿の方が困る。
エレガントに見えて追跡不能である場合が多い。
660 名前：デフォルトの名無しさん ：04/08/04 18:44: >>659
>他人に使われることを想定してクラスを作ったら、
>クラス内部からスローするような仕様は下の下だということに気付けるはずだ。

どうしてクラス内部からスローするような仕様は下の下なんですか？
あなたの>>563の発言からして核心はそこだと思うのですが。
661 名前：デフォルトの名無しさん ：04/08/04 18:45: 核心を伝えよう。

この業界ではプロ==バカ
662 名前：デフォルトの名無しさん ：04/08/04 18:45: >>651
お前やっぱりアホだろ。

自分で例外を投げても、そのコードを利用するクライアントから見たら、
クラス内で勝手に例外が発生してるんだよ。
現在のスコープより上位に投げないと言うのなら goto で十分だ。

それとも、まさか再利用される可能性の無いアプリケーション固有の
コードでのみ例外をしようして、人が触る可能性のあるコードでは
例外を送出しないとか言うのか？

馬鹿避けと例外安全を勘違いしまくってるだろ。
663 名前：デフォルトの名無しさん ：04/08/04 18:45: あんまプロ、プロ言わんほうがいいな…
664 名前：デフォルトの名無しさん ：04/08/04 18:45: >>659
そうだそうだ。563様は偉大なんだ。例外処理についての素晴らしい独自理論をお持ちなんだ。
その理論は門外不出なのに、私たちのためにちょっとだけ教えてくださったんだ。

例外設計を知らないわけじゃないんだぞ。
665 名前：デフォルトの名無しさん ：04/08/04 18:46: >>661
マ板見ると良く分かるよな
666 名前：デフォルトの名無しさん ：04/08/04 18:47: >>563 はマ板のあちこちに現れては、
バカな主張を行う人なのでスルーした方が吉です。

特徴
・言葉遣いが汚い。いきなり他人を「お前」よばわりする
・自分の主張を補強する事実は一切ださない
・抽象的な主張の論拠として、さらに抽象的な主張を持ち出す

頭が悪いだけで、悪意はなさそうなんだけど・・・・
667 名前：デフォルトの名無しさん ：04/08/04 18:47: >>659
技術を共有する気の無い奴は二度と来ないでくれ。
馬鹿対策は実世界で個人的にやってくれ。
668 名前：デフォルトの名無しさん ：04/08/04 18:48: >>662
＞それとも、まさか再利用される可能性の無いアプリケーション固有の
＞コードでのみ例外をしようして、人が触る可能性のあるコードでは
＞例外を送出しないとか言うのか？

最善だと思うね。一切のオタク色を排除すればそうなる。
669 名前：デフォルトの名無しさん ：04/08/04 18:48: 流れはやいなー
670 名前：デフォルトの名無しさん ：04/08/04 18:49: 煽りがちと気持ち悪いくらい度が過ぎてるので、563の方がまともに見えてきたな
671 名前：デフォルトの名無しさん ：04/08/04 18:49: 盛り上がっているところ恐縮ですが、ifstream が例外を投げないという仕様は皆さんから見て自然なんですか？
672 名前：デフォルトの名無しさん ：04/08/04 18:49: >>666 よく見てるな・・・
673 名前：デフォルトの名無しさん ：04/08/04 18:51: C++が廃れた理由が良く分かるよ
674 名前：デフォルトの名無しさん ：04/08/04 18:51: >>671
例外処理のあるまともな言語は全て投げてる。
675 名前：デフォルトの名無しさん ：04/08/04 18:51: >>668
他人にも分かる言葉を使って欲しい。
676 名前：デフォルトの名無しさん ：04/08/04 18:53: これはひどい・・・
677 名前：デフォルトの名無しさん ：04/08/04 18:53: >>563はともかくとして、アレコレの API のエラー検出は結局戻り値チェックでやってるので、
API 含有率が高いプログラム書いてるときは例外使いたくなくなることもあるな。

でも「MFC （の CFile）がタコだから例外はダメ」って程度しか論拠を示されないんじゃ、
あまり納得いく論議ではないなぁ・・・MFC みたいにバカが使うライブラリは、例外とか
テンプレートとか使うべきじゃないっていうことなら同意できるけど。
678 名前：デフォルトの名無しさん ：04/08/04 18:53: 666=672
679 名前：デフォルトの名無しさん ：04/08/04 18:55: STLはバカは使わないのか
680 名前：デフォルトの名無しさん ：04/08/04 18:55: 例外を投げないライブラリに例外を投げるラッパを書くのは手間だけで済むが、例外を投げるライブラリのパフォーマンス上のペナルティは回復しようが無い。
よって例外を投げないほうがまだマシ。
681 名前：デフォルトの名無しさん ：04/08/04 18:55: >>678
そんな地味な自演を指摘されても（笑
682 名前：デフォルトの名無しさん ：04/08/04 18:55: >>680
例外は滅多に起きないから例外って言うんですよ。
683 名前：デフォルトの名無しさん ：04/08/04 18:56: >>680
Cとかアセンブラでも使ったら？
C++が廃れた理由が良く分かるよ。
684 名前：デフォルトの名無しさん ：04/08/04 18:58: >>680みたいな事言う香具師に限って線形アルゴリズム乱用したりするんだよね。
685 名前：デフォルトの名無しさん ：04/08/04 18:58: >>680
>例外を投げるライブラリのパフォーマンス上のペナルティ

それホント？
本当だとしても、例外がパフォーマンスに影響するような設計が悪いんじゃないの？
686 名前：デフォルトの名無しさん ：04/08/04 18:59: >>680

80,20の法則って知ってる？
687 名前：デフォルトの名無しさん ：04/08/04 18:59: 内心basic_stringの例外クラスout_of_rangeとかウザイと思ってるヤシ、手挙げろ。
素晴しいとか思ってるのはC++ヲタだけじゃねーの？
688 名前：デフォルトの名無しさん ：04/08/04 19:00: >>682
めったに投げなくても、投げられる可能性があるなら
とりあえず受けておくべきなのが例外ですよ。
で、受けるコードでもペナルティが発生するんです。
689 名前：デフォルトの名無しさん ：04/08/04 19:00: >>680は完全に正しい。
C++で最高のパフォーマンスを引き出すコードを記述する場合には。

そして>>680は完全に間違い。
C++でパフォーマンスよりも生産性を重視した開発を行う場合には。

C++は特にいろんな前提条件があるんだから断定はできないだろ。
例外がいやならstd使うななってこった。少なくともその自由は与えられているはずだ。
690 名前：デフォルトの名無しさん ：04/08/04 19:01: >>687
拾わなきゃいいんでない。拾わなきゃどのみち落ちるんだし。
691 名前：デフォルトの名無しさん ：04/08/04 19:01: >>687
atなんか使わないから、しらん。
692 名前：デフォルトの名無しさん ：04/08/04 19:02: >>688
それと、戻り値で返されたエラーをifで処理するのと、どっちがパフォーマンスに優れていると思っているのだ？
693 名前：デフォルトの名無しさん ：04/08/04 19:03: >>692
そりゃifだよ。
694 名前：デフォルトの名無しさん ：04/08/04 19:03: アメリカのForum回った後に、ここ来るとがっかりするな
695 名前：563 ：04/08/04 19:04: >>689
＞例外がいやならstd使うななってこった。少なくともその自由は与えられているはずだ。

その自由さえ制限してしまうのが、クラスの例外スロー。
クラスの例外スローがお前らに何を与えてくれたというのだ？
不便な束縛だけだろう？目を覚ませよ、いい加減。
696 名前：デフォルトの名無しさん ：04/08/04 19:04: >>695
例外が嫌なら例外吐くクラス使うなよ
697 名前：デフォルトの名無しさん ：04/08/04 19:04: >>691
今調べたら、append等でもout_of_range投げるんだね。知らなかった。
確かにこれはちょっと余計かな。
698 名前：デフォルトの名無しさん ：04/08/04 19:05: >>695
>その自由さえ制限してしまうのが、
して無いだろ。std使うなといっている。cstdio使っとけ。
699 名前：デフォルトの名無しさん ：04/08/04 19:05: >>695
695の言ってる「クラスの例外スロー」の意味がわからないのは私だけ？
700 名前：デフォルトの名無しさん ：04/08/04 19:06: >>695はC時代からのプロでもう年だから
どうしてもtry,catch構文が覚えられないだけなんだ。
そっとしておいてやれ。
701 名前：デフォルトの名無しさん ：04/08/04 19:08: >>699
695 =563語の「クラス」ってのは、たぶんクラスライブラリのことを意味しているんだと思う。
ハードディスクのことを「ハード」っていう人、稀にいるみたいだし。
702 名前：デフォルトの名無しさん ：04/08/04 19:08: >>563は過去に例外をcatchし忘れて
クリティカルなアプリが落ちてトラウマになっている。
703 名前：デフォルトの名無しさん ：04/08/04 19:08: >>690
そりゃそうだけど、落ちるほどのことか？
個人的には、なにもせずに戻してもいいと思うね、この程度なら。
ま、派生クラスでオーバーライドすりゃいいんだけどさ。
704 名前：デフォルトの名無しさん ：04/08/04 19:10: >>699
コンストラクタが投げる例外のことじゃないかと憶測
705 名前：デフォルトの名無しさん ：04/08/04 19:10: まあ他人も使うクラスなら「例外吐くなら例外仕様くらい書けよ」というなら
同意だが、「例外吐くなよ」はどうかな。
706 名前：593 ：04/08/04 19:11: >>702
まあな。テスト段階での話だけどな。
苦い目にあったことのない日曜PGには、漏れの堅牢な哲学なぞわからんだろ。
707 名前：デフォルトの名無しさん ：04/08/04 19:11: >>704
コンストラクタが例外吐かなかったら
構築に失敗した時どうするのだろう…
ああ、またGetLastErrorか(w
708 名前：デフォルトの名無しさん ：04/08/04 19:12: >>593
具体例を提示できないならいい加減消えな
709 名前：デフォルトの名無しさん ：04/08/04 19:13: 例外の言語仕様は
Java＞＞＞＞＞＞＞＞＞C++
710 名前：デフォルトの名無しさん ：04/08/04 19:13: >>708
何の具体例？
711 名前：デフォルトの名無しさん ：04/08/04 19:14: 593はtry,catchも忘れるようなアフォ
712 名前：デフォルトの名無しさん ：04/08/04 19:16: >>706
藻前は>>593じゃなくて>>563だろ。
自分の番号まで間違えるくらいだから
try,catchも忘れるんだな(w
713 名前：デフォルトの名無しさん ：04/08/04 19:17: つーか>>563が無知なのは分かったから、
いい加減消えてくれないかな。
714 名前：593=706 ：04/08/04 19:17: 名前は>>593じゃなくて、>>563。

>>707
コンストラクタに色んなことをやらすのは、アフォ。
常識っしょ。
715 名前：デフォルトの名無しさん ：04/08/04 19:18: 以上プロ==バカの典型的な例でした。
716 名前：デフォルトの名無しさん ：04/08/04 19:18: 本日のNGワード：593
以上
717 名前：デフォルトの名無しさん ：04/08/04 19:18: >>707
例外を吐くような処理はコンストラクタじゃなくて初期化用メンバ関数でやれ、とか書いてたのはCマガだっけか(w
718 名前：デフォルトの名無しさん ：04/08/04 19:20: 以下ExceptionalC++さえ呼んでない香具師は
例外に関する発言禁止。
719 名前：デフォルトの名無しさん ：04/08/04 19:21: んじゃまずお前が呼んできてくれ
720 名前：563 ：04/08/04 19:21: >>712
＞try,catchも忘れるんだな(w

漏れがtry,catchを実装しても、投げてくるブツが違ったらどうしようもない。
catch(...)でどうにかなるほど甘くない環境での話だ。
721 名前：デフォルトの名無しさん ：04/08/04 19:22: >>720
>catch(...)でどうにかなるほど甘くない環境
すでにC++ではありませんね。スレ違いです。
722 名前：デフォルトの名無しさん ：04/08/04 19:23: >>714
オブジェクトにいちいち初期化完了ステータスとかを持たせるのか？
723 名前：デフォルトの名無しさん ：04/08/04 19:24: Init呼ばないとオブジェクトが動かないんじゃないの？(w
724 名前：デフォルトの名無しさん ：04/08/04 19:24: つーか、catch(...)したらどうせ再throwするんだからcatch(...)で済む状況ってあるのか？
725 名前：デフォルトの名無しさん ：04/08/04 19:25: 720は戻り値チェックでも間違った比較をしまくってそうだな。
726 名前：デフォルトの名無しさん ：04/08/04 19:27: main(){
　try {
　　～
　}
　catch(...) {
　　～
　}
}

回復可能か不能かは別として、とりあえずデバッグ時に
漏れたのキャッチするようにしておけば、キャッチ漏れには
すぐ気づくんじゃないか？
727 名前：デフォルトの名無しさん ：04/08/04 19:27: catch(const std::exception&)でいいんじゃないの？
例外でintとかstring投げるのは>>563くらいだろ(w
728 名前：デフォルトの名無しさん ：04/08/04 19:27: 例外が出来た経緯とか、正しい答えがある風なエラそうなこと言っていた割には
誰一人とて納得させてないんだよな。
729 名前：デフォルトの名無しさん ：04/08/04 19:29: >>563に釣られすぎ
730 名前：デフォルトの名無しさん ：04/08/04 19:29: 納得させてないんじゃなくて
頑なに納得しないんだよ。
731 名前：563 ：04/08/04 19:30: >>726
そこからが長かったりする。
進捗報告に1行で記述する項目であっても労力は雲泥の差だ。
732 名前：デフォルトの名無しさん ：04/08/04 19:33: >>720
それはドキュメントの質が悪いんじゃない？
例えば CFile は CFileException 投げるって書かれてて、それはその通りなんだけど、
CSocketFile のドキュメントには何も書かれてないくせに、
でもコイツは CInvalidArgException 投げる、とか。
733 名前：デフォルトの名無しさん ：04/08/04 19:33: >>731
>>727
734 名前：563 ：04/08/04 19:33: >>722
つまりステータスを持つなと？
iostream系はアフォと？

>>723
状況によっては正しい。
再利用のない、単純クラスしか使ったことがない>>723には理解できんだろうけどな。
735 名前：デフォルトの名無しさん ：04/08/04 19:36: ここまで頑固だとそのうちクビになりそうだな
736 名前：デフォルトの名無しさん ：04/08/04 19:37: >>734
初期化ステータスなんか持たせないで、NULLで十分じゃないか。
Initが悪なんて誰も言ってない。お前が常にInitを使うといってるだけだ。

コンストラクタでオブジェクトを構築しないみたいだからな。
737 名前：563 ：04/08/04 19:39: 今日はこのスレ、とりわけレベルが低かった。
実用性無視の学者肌の輩が多かったせいか。

無知を相手にしててそこそこ楽しかった、ﾉｼ
738 名前：デフォルトの名無しさん ：04/08/04 19:39: 以上典型的バカでした。
739 名前：デフォルトの名無しさん ：04/08/04 19:40: 170レス位釣れたな。良かったな。>>563
740 名前：デフォルトの名無しさん ：04/08/04 19:42: >>736
そこまで具体的な変数管理を想定できるなら、
まずインスタンス利用時にエラーチェックして
クラス外部でスローなりなんなりした方が利用者負担がなくてｲｲと思う。
なんでわざわざコンストラクタからスローするのかと小一時間（ｒｙ
741 名前：デフォルトの名無しさん ：04/08/04 19:42: だよねぇ。
CFile 使って例外取りこぼして障害発生なんて恥ずかしぃ・・・
そんなの発見するのに
＞そこからが長かったりする。
だって。

中国人使ったほうがマシだな。
742 名前：デフォルトの名無しさん ：04/08/04 19:42: http://diary5.cgiboy.com/2/i_love_u/
この日記って書いてることやばくね？通報されたりしないのかな？
画像とかも無断で使用しすぎだし・・・
743 名前：デフォルトの名無しさん ：04/08/04 19:44: コンストラクタから例外なげれば
構築済みの(基底クラスやイニシャライザの)デストラクタが全部自動で
走るから楽だよ。
744 名前：740 ：04/08/04 19:47: >>741
誰に対する同意？
自分は例外クラス否定派だけど（ｗ

いい中国人使った事あるの？
基本的にダメダメだと思うが。
745 名前：デフォルトの名無しさん ：04/08/04 19:50: >>744
同じダメなら人件費安いほうがいいってことだと思う。
でも 563 はダメなりに頑張って最後には動くもの作るんだろうから、
まぁ仕事放り投げちゃう中国人よりは使える場面が多いかもね。
746 名前：デフォルトの名無しさん ：04/08/04 19:51: >>743
コンストラクタから例外投げなかった場合でも
構築済みのデストラクタが全部自動で走ると思うが・・・。
どういう優位性を主張しているのかわからない。
747 名前：デフォルトの名無しさん ：04/08/04 19:54: 同じことをするんだから
フラグを用意する手間が省けませんか？
deleteもいらないし。
748 名前：デフォルトの名無しさん ：04/08/04 19:55: 中国人に一目置くとは、程度が知れてる（ｒｙ
読解力もなさげだし（ｗ、>>741。
749 名前：デフォルトの名無しさん ：04/08/04 19:58: お前ら良く中国人と一緒に仕事なんてできるな。
内心では無茶苦茶憎まれてるよ。
たぶん意図的に致命的なバグ山ほど仕込まれてるよ。
プロジェクトが崩壊する前に早くクビにした方がいい。
750 名前：デフォルトの名無しさん ：04/08/04 19:58: サッカー見てたらますます怖くなったよ＜中国人

■過去ログ置き場に戻る■ 1- 前250 次250 最新50

DAT2HTML 0.33f Converted.