[過去ログ] C++相談室 part165 (1002レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) レス栞 あぼーん

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
236
(2): デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/11(日) 03:08:09.08 ID:4PD3HqyC0(1/5) AAS
>>232
232(2): デフォルトの名無しさん (ワッチョイ ffcf-HxQs) [sage] 2024/02/10(土) 20:56:08.28 ID:0f3gz8pL0(2/3) AAS
>>228
>>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……

どこが論外?>>169でぜんぜん問題ないが。
それは未知の例外投げてきた原因を調査しなさすぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね

>>233
233(2): デフォルトの名無しさん (ブーイモ MM8f-tai3) [sage] 2024/02/10(土) 21:22:31.20 ID:dL54PN9cM(1) AAS
>>232
それは未知の例外投げてきたライブラリを信用し過ぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね
ドキュメント通りに例外発生条件にならないように呼んでやったのに
例外を飛ばしてくるライブラリって一体……
製品やぞ……
237
(2): デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/11(日) 03:16:41.24 ID:4PD3HqyC0(2/5) AAS
質問なのですが
Q1. std::ldexp(0.0, 0.0) が0.0なのですがこれは 0^0 = 0という大胆な主張なのですが何で決まっているの?
STLがIEEE735に従っているだけ?

Q2. 最小の(絶対値が最小の正の)非正規化数は
const auto min_expn = std::numeric_limits<double>::min_exponent;
const auto digits = std::numeric_limits<double>::digits;
として、std::ldexp(0.5, min_expn - digits + 1) で正しい?
(実際 std::ldexp(0.5, min_expn - digits + 1) > 0.0 やが std::ldexp(0.5, min_expn - digits + 1) / 2.0 == 0.0 であっる

Q3.にもかかわらず、
std::ldexp(0.5, min_expn - digits) > 0.0 になるのはなんで……orz
238: デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/11(日) 03:25:12.56 ID:4PD3HqyC0(3/5) AAS
訂正 |||。n_
誤1: IEEE735
正1: IEEE754
誤2: 非正規化数
正2: 非正規数
248
(1): デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/11(日) 11:18:37.96 ID:4PD3HqyC0(4/5) AAS
>>231
231(1): デフォルトの名無しさん (ワッチョイ ffcf-HxQs) [sage] 2024/02/10(土) 18:55:23.41 ID:0f3gz8pL0(1/3) AAS
>>229
>例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……

いったい何をテストしようとしているんだろうか。
仮に「例外が飛んでこないことを確認するテスト」なるものができたとして、catchしたらそれができなくなるのか?

前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか。
>前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか
例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言
1. catchが書かれた関数が正しくcatchし、適切に処理するか(処理してせき止め or/and 必要な場合再スロー)(←要テスト!
2. fall-throughする関数が例外による処理の中断でおかしいことにならないか(←要テスト!

2をテストもせずに放置するとおかしくなる例は>>183
183(6): デフォルトの名無しさん (ワッチョイ 6d63-H5uA) [sage] 2024/01/28(日) 12:13:11.85 ID:W0uCnQb30(3/4) AAS
>>182
>catchしようがしまいが、例外が起きて 処理A→B→return となるのは同じだと思うが。
それは問題の認識がおかいし
例えば以下のコードにおいて、スレッドのゾンビを生じさせないためにはfuncB()をtry { } catch () { } は必須になる。
 void bar() {
  funcA();  // スレッドxを起動
  funcB();  // 中でbaz() → foo()の呼び出し
  funcC();  // スレッドxに停止シグナル発酵
  funcD();  // スレッドxの終了待ち
  return;
}
このように一般に例外が飛んでくる関数にはcatchするかしないかの選択権など無い
例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない

一方、例外を生じないライブラリの使い方(関数の呼び出し方)を心掛けるかどうか。これなら選択肢がある
のとうーり
これにより、例外を生じる関数foo()の呼び出しパティーンn個それぞれに対し、a個のテストが必要になっる
例外を発生させない使い方をするなら、n*a*mではなくmの定数倍(例外を飛ばさない使い方に依存擦る定数)。
例外が飛んで来たらバグ。わかりやすい

例外を多用しつつn*a*mをよくわからない計算とか言っている時点で以下略
249
(2): デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/11(日) 11:18:50.45 ID:4PD3HqyC0(5/5) AAS
>>244
244(2): デフォルトの名無しさん (ワッチョイ 1e27-2ki6) [sage] 2024/02/11(日) 09:47:48.79 ID:2tL2xZqD0(2/3) AAS
>>242
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか?
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う?
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する(>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする(m個のオーダー)(>>229
229(2): デフォルトの名無しさん (ワッチョイ 5763-dZsi) [sage] 2024/02/10(土) 12:26:53.58 ID:KJGevrBa0(2/2) AAS
>>186
>catchしたらテストケースが増えるかどうかという話とはなんも関係がない。
あっる
catchする必要性箇所を設計で厳選すればcatchが減るのだからテストケースは減らし得る

例外を使う場合:
スルーしたりcatchして再スローが生じるfoo()の呼び出し箇所(とするのが現実的でないなら呼び出しパティーン)がm個、
スルーしたりcatchして再スローする段数が(簡単のためここでは平均とする)a個、
foo()が例外を生じるパティーンがn個なら、m^a^n個のテストケースが必要なところであるが

catchする必要性箇所を設計で厳選した場合:
foo()の呼び出し箇所(とするのが現実的でないなら呼び出しパティーン)がm個だとしたら、
例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる(>>228
228(3): デフォルトの名無しさん (ワッチョイ 5763-dZsi) [sage] 2024/02/10(土) 12:18:06.78 ID:KJGevrBa0(1/2) AAS
>>185
>>183の主張の
>一方、例外を生じないライブラリの使い方(関数の呼び出し方)を心掛けるかどうか。これなら選択肢がある
が完全に読み飛ばされている件について:

例外を生じないライブラリの使い方で設計したら、funcB()から例外が飛んでくるのはバグなので
調査と修正の対象になる。
(結果的にやっぱtry { funcB(); } catch (/*略*/) { ... } いるじゃーん?となる可能性はあるがたいていはそうはならない

>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……
 例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
  (ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
  結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある(>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
  正常な動作の継続を意図する場合はテストケースが爆発する(>>

設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ;;;

いっぽう藻前らの主張は
1. 例外をせき止めれば良い(←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
 (←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.034s