5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

例外処理の効果的な使い方

1 :1:2001/08/02(木) 22:49
みなさん、例外処理って使ってます?
なんか例外処理をプログラムにいれると、
ソースが汚く(+長く)なるような気がします。
例外クラスとか作ってますか?
言語は例外処理をサポートしているものすべて対象にします。

2 :デフォルトの名無しさん:2001/08/02(木) 23:00
当然使ってます。使わないとマトモなコードが書けないとは
言いませんが(Mozillaとか)、使いたくない理由が知りたい。
長く汚くなる実例をくださいな。

もしくは、
ttp://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html
の「ほげ言語」のパラドックスでも読んでください。

3 :デフォルトの名無しさん:2001/08/02(木) 23:08
いちおう使ってます。
まだへぼいプログラムしか書けないので、
ネストが深くなりすぎる時に意味不明になってますが、、。

4 :デフォルトの名無しさん:2001/08/02(木) 23:21
>>1
Javaは例外を拾ってあげないとコンパイルもできないよ。
エラーを言語が判断してくれるのだから楽でいいじゃん。

5 :デフォルトの名無しさん:2001/08/03(金) 00:31
>>2
Mozillaは例外処理をしてないんですか?

6 :2:2001/08/03(金) 00:47
http://www.mozilla.org/hacking/portable-cpp.html#dont_use_exceptions
を見てもらえばわかりますが、移植性を確保する目的で例外(try, catch, throw)は使っていないです。

#エラーのハンドリングを何もしていないという意味ではないですw

7 :5:2001/08/03(金) 01:00
>>6
そういうことだったんですね。
エラーが起きたらどうするんだろうと真剣に悩んでましたw
どうもありがとうございます。

8 :デフォルトの名無しさん:2001/08/03(金) 01:30
1はどこいった?
終了?

9 :デフォルトの名無しさん:2001/08/03(金) 14:47
>>6
つまりここでもガンはC++であるわけだ(わら
もうちょっと「まともな」言語に移ったほうがいいよ。

10 :デフォルトの名無しさん:2001/08/03(金) 15:05
>>9
目的は移植性を確保するためだろ?
もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
てるものがあるのか?

11 :デフォルトの名無しさん:2001/08/03(金) 16:30
>>1 の言い分は単純に「エラー処理したくない」だと思われ。

12 :デフォルトの名無しさん:2001/08/03(金) 17:42
if文をネストしまくって事実上エラーが出ないようにするのは可能?

13 :2:2001/08/03(金) 19:00
>>11
おれもそうじゃないかと一寸思ってた。やっぱそうなのか。

>>9
C++が駄目な点はいろいろあるとは思うし、例外についてもJavaの様に
catchを強制してくれたほうが却って有難いとは思うよ。そういう縛り
を入れてくれるコンパイラなりプリプロセサなり、ないかな?

14 :デフォルトの名無しさん:2001/08/04(土) 12:02
みな厨房

15 :デフォルトの名無しさん:2001/08/04(土) 12:04
   ∧_∧
 ( ´∀`)       
 (    ) オメモナー
  |  | |
 (__)_)

16 :デフォルトの名無しさん:2001/08/04(土) 12:20
>>12
それを「エラー処理」っていうんだYO!

17 :デフォルトの名無しさん:2001/08/04(土) 19:46
例外なしC++でエラーや例外を処理するとなると、
goto文を多用することになりますが、そんなもんですかね?
auto変数のデストラクタで処理するというのもあるけど・・・

18 :デフォルトの名無しさん:2001/08/04(土) 21:26
try:
厨房指ネ
except 帰り打ち:
raise "オマエモナー"

19 :デフォルトの名無しさん:2001/08/04(土) 22:16
>>13
>例外についてもJavaの様に
>catchを強制してくれたほうが却って有難いとは思うよ。そういう縛り
>を入れてくれるコンパイラなりプリプロセサなり、ないかな?

だからといっていまさらそんな縛りを入れられても困る。

20 :デフォルトの名無しさん:2001/08/04(土) 22:20
try {
  kill(chubo);
} catch (BOUSOU_Exception) {
  kill(THREADS);
delete[] chubo;
}

21 :デフォルトの名無しさん:2001/08/05(日) 00:41
↑超効果的な使い方じゃん!

22 :デフォルトの名無しさん:2001/08/05(日) 00:49
>>17
ほとんどの場合、スマートポインタを使えば goto 不要だと思うが。

23 :デフォルトの名無しさん:2001/08/05(日) 01:03
VBの例外処理の地獄に比べれば、天国とは言わないが
中つ国程度にはマシだと思うのだがどうか。>C++例外

24 :ナーナス:2001/08/05(日) 04:18
C++の例外はexception-safeなclassを作るためのsupportが素晴らしい。

25 :デフォルトの名無しさん:2001/08/05(日) 06:12
http://www.muvc.net/kpgy/man.html

26 :デフォルトの名無しさん:2001/08/05(日) 09:48
finallyない言語は糞言語

27 :デフォルトの名無しさん:2001/08/05(日) 11:07
>>26
論述が苦手なのかい?

28 :デフォルトの名無しさん:2001/08/05(日) 12:27
前提:C++だろ。Cは関係ない。そこをごっちゃにすると話が進まない。

>>10
>目的は移植性を確保するためだろ?
>もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
>てるものがあるのか?

それは明らかに本末転倒な反論だろう。
移植性といっても、CPUの違いによる制約とか
(GCとかではそういうことは有るね。boehmとか)
ならともかく、既存のC++処理系の上での話なんだろ?
じゃあC++処理系を直せとしか言いようが無いね。

ていうか「もっとましな言語」を望む環境に移植すればいいんだろ?
じゃあCかなんか(わら)で書かれたソレをその環境用にmakeすればいいんだよ。
勿論C++についてもgccで同じことをすればいいだけだし。

と書いてもなお納得できないならSqueakの話でも読むべし。
http://www.mars.dti.ne.jp/~umejava/smalltalk/squeak/index.html
勿論、Squeakが普及してるとか普及させろとかを、ここでいう積もりではなく。


>>27
26は必要最低限にして十分な内容を記述していると思われるが?

29 :デフォルトの名無しさん:2001/08/05(日) 12:43
>>28

> それは明らかに本末転倒な反論だろう。
言語仕様と現実の処理系の完成度とを意図的に混同する事はないと思う。

> 26は必要最低限にして十分な内容を記述していると思われるが
必要十分条件って知っていて言ってる?
おそらく >>26>>28 はC++嫌いで通底しているから説明が不要だと思い込んでいる。

30 :26>27:2001/08/05(日) 14:14
自明です

31 :27>26:2001/08/05(日) 15:23
不毛です

32 :デフォルトの名無しさん:2001/08/05(日) 16:00
>>26
C++ ではデストラクタの呼ばれるタイミングが明白なので、

1. デストラクタに後始末させる設計にしておく
2. スマートポインタ(もしくはローカル変数)を使う

で finally なくても困らんけどな。

33 :デフォルトの名無しさん:2001/08/05(日) 16:08
そうだね structで関数内ローカルに そのためだけにクラス作ってやればいいでしょ

func(a,b)
{
 struct {
 デストラクタで後始末
 } My;
My.func(a,b); //コンストラクタにしてもいいけど

}

34 :デフォルトの名無しさん:2001/08/05(日) 17:53
>>32
それはfinalize()では?

35 :デフォルトの名無しさん:2001/08/05(日) 18:53
>>34
何を言いたいのか不明なんだけど、

 Java の finalize() は呼ばれるタイミングが決まっていないので、
 finally ブロックの代わりに自動変数のデストラクタを使うことは
 できません。

で答えになってる?

C++ はデストラクタにお任せで済むのが便利なんだけど、代わりに注
意しないとリークが発生しやすいのが難ではある。

EXCEPTION HANDLING: A FALSE SENSE OF SECURITY
http://cseng.aw.com/book/related/0,3833,020163371X+11,00.html

36 :1:2001/08/05(日) 20:01
1です。いろいろ意見をありがとうございます。
ご想像の通り、C++はじめて1年ちょいの厨房です。

ソースが汚くなるというのは、関数1つ書くのに、
catchをいくつも書いたりして、それがたくさんになってくると
冗長な感じがしたので、こんなスレをたてました。
いままで、自分がみたC++のソースでまともに例外処理を使っているのを
みたことがありません。
どっかに良い例はありませんか?

37 :デフォルトの名無しさん:2001/08/05(日) 20:03
つーか汚くて冗長で悪い例をあげてみ?

38 :2:2001/08/05(日) 21:09
おれもきぼん(再)

39 :ナーナス:2001/08/05(日) 22:25
>>35
> EXCEPTION HANDLING: A FALSE SENSE OF SECURITY
> http://cseng.aw.com/book/related/0,3833,020163371X+11,00.html

これを初めて読んだ時は衝撃!
T pop(stack<T>); という仕様自体がexception-safeでないとは!
「実装」でなく「仕様」がexception-safeでないという事の理解は、
これ読んだ後のprogramming style/designにかなり影響を与えた。

>>36
SmartPtrが、 NullPointerExceptionをthrowする、
なんて所だけで十分にいかしていると思うが?
操作するたびに値をcheckする気するかぁ?

40 :デフォルトの名無しさん:2001/08/05(日) 23:16
>>29
>言語仕様と現実の処理系の完成度とを意図的に混同する事はないと思う。

はぁ?むしろ、

>>もうちょっと「まともな」言語とやらでC/C++ほど多くの実装系に移植され
>>てるものがあるのか?

のほうが混同してるのだと思うが?

>>32 >>33
つまり「例外出ようが出るまいが必ず通るコード」を
「局所クラス(のインスタンスのデストラクタ)」でエミュレートしようというわけね?

…「綺麗」ではないね。

念のため言っておくけど、
「必ず通るコード」が常に1つのObjectとして(デザイン的に)表現されるのが自然か?
というと、そんなことは無いわけだから。

>>34
全然違うぞ(^^;
finalizeとfinally(とついでにfinal(わら))とは別モノだ。

41 :デフォルトの名無しさん:2001/08/05(日) 23:18
ちうか例外ってOOPとは、まったく異質な機構なんで
ソースに加えると違和感が残る。
よって俺は使ってません。

42 :デフォルトの名無しさん:2001/08/05(日) 23:21
>>40
例外の話をするのでなければスレ違い。オブジェクト指向言語の実装
の美しさについて語りたいなら、別スレッドに逝ってくれ。

43 :デフォルトの名無しさん:2001/08/05(日) 23:22
Delphiの
try
 try
  ...
 except
  on E: Exception
   ;
 end
finally
 ...
end
ってやたらとインデント深くなるのは何とかならんのか
ついでにexceptに対になる例外が出なかったときのみ
実行されるブロックが欲しいな。まあなくてもあんまり困んないけど。

44 :デフォルトの名無しさん:2001/08/05(日) 23:28
>>41
例外機構ってどっちかというとアスペクト指向なのかもね。

45 :デフォルトの名無しさん:2001/08/05(日) 23:32
ちうかC++のintってOOPとは、まったく異質な機構なんで
ソースに加えると違和感が残る。
よって俺は使ってません。

46 :デフォルトの名無しさん:2001/08/05(日) 23:37
>>41
たしかに別ものではあるが、互いに「相性」は良いと思うのだが。
XPのプラクティスみたいに、互いが互いを必要とするみたいな。

>>43
>exceptに対になる例外が出なかったときのみ

それは時折思う。というかFinallyって
例外出た時(except相当)と出なかった時のどっちも同じ実行パスになる、
というだけだから、アトミックに考えるとexceptとnon_exceptさえ有ればいい
のかも知れず。

こないだ作った自作言語でそれっぽい実装にしてみた。

try foo bar zot
#foo/bar/zotは手続きへのポインタ。
#この言語では無名手続きを任意の場所で書ける。

っていう感じで、fooを実行して例外だったらbarを、例外じゃなかったらzotを、
実行するっていう文法(?)にした。

で、手続きポインタなので、ポインタを2回参照しちまえばいいのね。つまり、

ex={finally処理の無名手続き}
try {hogehoge} ex ex

これでfinally相当の出来あがり。hogehogeが例外起こしても起こさなくてもexに飛ぶ。

47 :デフォルトの名無しさん:2001/08/05(日) 23:44
つーか、コンストラクタがエラー値を返せないから例外使うんじゃないの。
別口で init() 呼ぶとかいうなよ。

48 :43:2001/08/05(日) 23:52
>>46
>アトミックに考えるとexceptとnon_exceptさえ有ればいい
>のかも知れず。
exceptとnon_exceptの共通処理をfinallyに記述しないと冗長になるので
try

non_except

except

finally

end
って構文が良いと思う。これならインデントも最小に抑えられるし。
いまのところ実装してるのRubyくらいかな?

Delphiはtry廃止してbeginにしちゃうとなお良いかも。
if xxx then
try

finally

end
なんてのが良くあるし、メソッドの一番外側のブロックでも例外処理できるので。

49 :デフォルトの名無しさん:2001/08/06(月) 01:07
>>41
ということは STL は使わず operator new も再定義してるんでしょう
か?

50 :ナーナス:2001/08/06(月) 02:59
>>47 追加
objectの中にerror flagとかいうなよ。

51 :>47:2001/08/06(月) 11:04
コンストラクタ以外に例外生成するメソッドなんてたくさんあるだろ

52 :デフォルトの名無しさん:2001/08/06(月) 11:29
>>40
綺麗じゃないかどうかは主観だと思うな
 他に方法あるとしたら、 catchして投げ返すしかないけど
 これだと同じ手続きを2個所に書かなけりゃいけないんじゃない?

 だとしたらそれよりは綺麗なコードだという視点もあるでしょ?

後は、では finally相当の為のコードである事をどう他人が読んでも
判るかという問題じゃないの?

まあ、関数やメソッド内で classじゃなくてstructでデストラクタ宣言
してたら9割はfinally代わり だと予想しながら読んじゃうけどね

53 :お願い名無しさん:2001/08/06(月) 12:19
>当然使ってます。使わないとマトモなコードが書けないとは
>言いませんが(Mozillaとか)、使いたくない理由が知りたい。

例外オブジェクトがメンバ変数を持っている場合、
正しく初期化できない場合があった。
exceptionからerrnoを持つクラスを導出したら
xexception::xeception(): errnumber(errno) {}
それを初期化できなかった。コアダンプすることもあった。
使っているコンパイラのバグだと思う。

54 :ナーナス:2001/08/06(月) 13:53
なんだ、使いたくないコンパイラがあるという話か。

55 :デフォルトの名無しさん:2001/08/06(月) 14:16
>>53
テンプレートや例外なんかは後から加わった機能なんで、以前は、実
装が甘い処理系があったのは確か。ただ、さすがに最近は例外まわり
でバグが残っている処理系は少ないと思う。

むしろ、今ごろそんなバグが残ってる処理系は捨てる準備を始めたほ
うが。過去の資産が……といって捨てずに後生大事に使っていたら、
コンパイラベンダ自体が撤退してサポート打ち切りとか、ありがちな
話。

そういえば、ゲームや組み込みなんかでは例外って使われてる? 主
記憶 64KB とかの世界だと C++ 自体がお呼びじゃないと思うけど、
最近のゲーム機って主記憶 32MB とか積んでるから、開発手法も以前
とは変わってると思うんだけど。

56 :デフォルトの名無しさん:2001/08/06(月) 14:20
例外というか LONGJMP なら使うな

57 :デフォルトの名無しさん:2001/08/06(月) 15:34
>>53
errno使うのは止めたほうがいいんじゃない?
マルチスレッド対策でマクロになってる処理系もあるし

58 :デフォルトの名無しさん:2001/08/06(月) 15:43
Javaはあまり詳しくないが、Javaのfinallyの話を聞いて
どうしてもC++でfinallyがほしくなって、こんなことをした覚えがある。

(ちょっと記憶あいまい、まちがっているかも。でも趣旨は伝わってくれると思われ)

class __finally_exception
{
};
class __finally_raiser
{
public:
  ~__finally_raiser()
  {throw __finally_exception;}
};
#define try_with_finally \
 try { \
  __finally_raiser __finally_raiser_object;

#define end_try_with_finally \
 }

#define finally \
 catch(__finally_exception&)


で、

try_with_finally
  .
  .
end_try_with_finally
catch(hogehoge_exception&)
{
  .
  .
}
finally
{
  .
  .
}

tryブロックの中にデストラクタで例外を投げるautoオブジェクト
作れば、tryブロックを抜けると例外が投げられるからそれをcatchする
ということです。

でも、アホらしくなって使うのやめた。

59 :#6411:2001/08/06(月) 16:58
>>55 主記憶 64KB とかの世界だと C++ 自体がお呼びじゃないと思うけど

主記憶64KBでコンパイラ処理系が使えるっていったら、
目が怒ライブかなあ? あの頃はC++自体が
マイナーだったし、そもそも漏れは瀬賀系にはあまり携わって
なかったような。Cだったら、基本的にはROM化の手法と
あまり変わらないんで、使いではあったとおもう。
主記憶2MBのプレ捨てでは、C++使ってた。
ただし、既存ライブラリは一切使わず、「便利なC」としての
使い方が多かったけど。(継承とかは使ってたよ)

漏れがC++に手をつけ始めた頃は、
gccに例外処理がまだ実装されてなかった。
鬱だ…

60 :デフォルトの名無しさん:2001/08/07(火) 01:39
>>58
>でも、アホらしくなって使うのやめた。
やめたのは正解かもしれないが、C++のトリッキーな技を垣間見たようだった。

61 :デフォルトの名無しさん:2001/08/07(火) 01:43
lispならfinally構文作って終りなのにね。
unwind-protectあるから必要無いけど。

62 :デフォルトの名無しさん:2001/08/07(火) 01:51
> xxならいいのにね。
xx厨房の典型的な書き込み

63 :デフォルトの名無しさん:2001/08/07(火) 02:00
ヒガムナ>62

64 :忠房:2001/08/07(火) 02:28
やっぱりlispがオススメれすか?

65 :デフォルトの名無しさん:2001/08/07(火) 02:39
win32の構造化例外処理は?

66 :デフォルトの名無しさん:2001/08/07(火) 02:39
ソフトウェア設計の書籍だと、オブジェクト指向でのクラス階層の
分析・設計は良く見かけるが、例外クラスの設計は見たことがない。
何かお勧めの文献(もしくは C++ ならソースコードでも良いけど)
あります?

67 :デフォルトの名無しさん:2001/08/07(火) 04:01
         ? ?
     プイッ/.⌒`.   ┌────────
      ヾ( ∈三∋) < シラネーヨ
  ナニッ!  /  / ̄    ノ)―───────
 ∧ Λ  (  ( ̄ ̄⌒ヽノノ
 ( ゚Д゚) ̄ \       Y
  U U ̄ ̄/ノ )ノ ̄)ノ\)

68 :デフォルトの名無しさん:2001/08/07(火) 21:48
>>66
>例外クラスの設計は見たことがない。

(よくみかけるような設計ほど大げさなものは)要らないと思う。

なぜなら、例外Objectって、これといって他のObjectと
関連とかなんとかを持ってないでしょ。
単にそのObjectが存在すればいいんです。例外Objectは。

あれは、全ての味噌はクラス継承ツリーです。
(設計者が)例外事象をどう「分類」したいと思ったか?を
そのままクラス階層にあらわせばいいんです。

例外Objectが有ったら、それに我々が期待する機能は、
「そのクラスがナニなのかを知る」
「ついでにエラーメッセージを持っていたらそれも読む」
くらいなもんです。

#だから逆にいえば、Reflectionの弱い言語だと、情けないことになるんだけど。

69 :デフォルトの名無しさん:2001/08/07(火) 23:03
例外を投げる場面、投げない場面の使い分けがよくわかりません。
MFCでも、例外なげてるのはFILE関連くらいで、ほとんどは戻り値でエラーを
知らせてますよね?
ていうかMFCを手本にするのが間違ってますか?

70 :ナーナス:2001/08/07(火) 23:18
>>66
例外のクラス階層も悩ましいのは悩ましいけど、
全体の仕様がチャンとして入れば、そんな難しくない。>>68のいう通り。

それより難しいのは、program全体をexception nuetralに作る事。
exceptionが起きた時に異常な状態にならないようprogrammingするのは、
そのconceptを知らない人には難しい。特に他人の作ったlibraryも使っている時は。

とりあえず、上のfalse senseは必読ですよ。
これ読まないで何度も使う予定のexeptionを使ったlibrary作っちゃ駄目。
”Exceptional C++"(C++ puzzle bookみたいなもの)にも載ってるよ。これは翻訳があるし。

http://cpptips.hyperformix.com/Exceptions.html
Guru of the Week, http://www.gotw.ca/gotw/008.htm

71 :ナーナス:2001/08/07(火) 23:26
>>69
> ていうかMFCを手本にするのが間違ってますか?

間違ってます。
Exceptionがなかった頃の設計ポリシーを引きずってます。

C++で閉じていいなら、どんどん使いましょう。

Windowsはsignal等、C++的でないものも存在して、
これはlanguage nuetralな機構だから、ないわけにもいかないよね。

72 :デフォルトの名無しさん:2001/08/08(水) 01:10
signalはどっちかっていうとunixでは?>71

73 :例外処理勉強中:2001/08/08(水) 01:18
C++でfinally代わり
try
{
Func();
Finally();
}
catch(char *str)
{
Error(str); //自分で作った例外の処理
Finally();
}
catch(...)
{
Finally();
throw; //その他なので外に投げ
}
どこ通ってもFinally()が呼ばれるということで…
こういうこととも違う?違うと思うので寝る。

74 :デフォルトの名無しさん:2001/08/08(水) 01:32
オートポインタとかauto変数にすんのじゃだめなの?>73

75 :73:2001/08/08(水) 02:11
>>74
勘違い。そっちのほうがな。
73は無かったことに…(;´Д`)

76 :デフォルトの名無しさん:2001/08/08(水) 04:59
例外導入はオブジェクト指向言語では必然的

77 :デフォルトの名無しさん:2001/08/08(水) 06:00
手続き型言語にも欲しいよ
オブジェクト指向に限定することないっしょ

78 :デフォルトの名無しさん:2001/08/08(水) 07:35
Eiffelの表明を使った例外処理が好き。

79 :デフォルトの名無しさん:2001/08/08(水) 11:44
エラー処理にgoto使うのは厳禁なんですか?

80 :デフォルトの名無しさん:2001/08/08(水) 13:17
ちょっと話は違うかもしれんけど、
DelphiのAbortっていいよね

キー入力をキャンセルしたけりゃ OnKeyPressでAbort投げるだけでいいし
とっても便利お手軽さん

81 :デフォルトの名無しさん:2001/08/08(水) 16:54
>>79
メソッド(関数)の呼び出し階層の深いところでエラーが起きたら
そこから一番上にはgotoできない。ので例外なりlongjmp云々な
わけで。

82 :デフォルトの名無しさん:2001/08/08(水) 22:57
>>77
欲しいってのは確かなんだけど、一方で、
例外の種類分けのための例外Class(の階層)を使えないのが悲しい。

ただ、逃げる手は有る(ので誰かそういう言語作ってくれ)。
階層を表現するために丁度いいデータ構造があればいいんだ。

一番卑近なものとして、ファイルのフルパスを連想すれば判るだろうけど、
「文字列」ってのが有ると思う。
つまり "Exception/IOException/FileReadException"
(冗長なので実用するときはもうちょっと縮めるのがお勧め)
みたいな文字列を使って例外分類をやる、という言語があればいい。

分類を吟味するときはもちろん部分文字列照合でヤル。
頭からマッチング調べればいい。
だから一番一般的な例外Object(?)は、 "" (空文字列)だと思われ(藁)

83 :ナーナス:2001/08/08(水) 23:49
>>72
スマソ、 SEHと書いたつもりでした。

SEH: Structured Exception Handling

84 :ナーナス:2001/08/08(水) 23:58
>>74
Destructorで済むものはそれでいいと思うけど、
利用方法依存の後始末をやりたい時にfinallyあれば嬉しい事もあるな。
CLOSの:after-daemonがあれば、使い捨てclassをon the spotに書けるのに。

VC++には、>>73みたいなマクロが__try/__catch/__finallyってなかったっけ?

85 :名無しさん:2001/08/09(木) 11:17
>>84
だから、
__try/__catchがSEH(構造化例外).
alarmに該当するのがRaiseException
signalハンドラに該当するのが__catchブロック
通常はSEH投げるとデストラクタをバイパスするんで×。
未定義の構造化例外を使ってC++のtry/catchが実装されててる。
これはthrowを__catchで捕らえるプログラム書いてテストすると分かる。

86 :85:2001/08/09(木) 17:54
__catch->__except()
鬱死。

87 :デフォルトの名無しさん:2001/08/09(木) 21:18
>>70
Exceptional C++ 買おうかと思うんだけど、邦訳の質はマトモですか? あまり
良くないなら原書を注文しようかと思ってます。

88 :デフォルトの名無しさん:2001/08/10(金) 02:29
age

89 :ナーナス:2001/08/10(金) 03:23
>>87
> 邦訳の質はマトモですか?

GoTWと原書を読んだので、知らない。

28 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)