[過去ログ] C++相談室 part165 (1002レス)
上下前次1-新
抽出解除 レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
283(5): デフォルトの名無しさん (ワッチョイ 1e85-XyAm) [] 2024/02/17(土) 23:18:00.46 ID:v62CV0mD0(1) AAS
>>278278(1): デフォルトの名無しさん (ワッチョイ 12ad-hHXc) [sage] 2024/02/17(土) 13:56:12.85 ID:mUyTgSzm0(3/4) AAS
俺も、(もしくは密に情報共有できている)なら、と言う話をしているがな
ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな
お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。
ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに *想定し* プログラムを組まなくてはならない
さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか?
そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
(ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な(処理の)出発点に戻るという意味でもある)
起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ
287(1): デフォルトの名無しさん (ワッチョイ e3f9-NGC7) [sage] 2024/02/18(日) 09:39:44.00 ID:9f8IS57r0(1/3) AAS
ぶっちゃけ>>283がなに言ってるのかわからない
継続してそれが原因で?
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ?
オブジェクトの状態が変わっているかも?
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か?
Topは0で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ
288: デフォルトの名無しさん (ワッチョイ cfcf-sYtR) [sage] 2024/02/18(日) 09:41:50.12 ID:WHoJTRhT0(1/2) AAS
>>285>例外の種類しか頭にないのか
>>283が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。
298(1): デフォルトの名無しさん (ワッチョイ 1b63-9XlH) [sage] 2024/03/02(土) 23:49:37.41 ID:C77pR/Zl0(2/3) AAS
>>284例外安全というもののスコープに対して考察が足りていない
1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は(メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない
2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
(つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない
299(2): デフォルトの名無しさん (ワッチョイ 1b63-9XlH) [sage] 2024/03/02(土) 23:57:46.67 ID:C77pR/Zl0(3/3) AAS
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
(例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等)
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというアフォはやっぱtry { } catch () しないのが正しい
305: デフォルトの名無しさん (ワッチョイ 8b63-eOBD) [sage] 2024/03/04(月) 07:58:21.27 ID:KYG2Ugpe0(1/3) AAS
なんか予想外に低レなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……
例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる(処理の順序が命)というアルゴリズムというものの本質的特性により、
>>183183(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せねばならない
一方、例外を生じないライブラリの使い方(関数の呼び出し方)を心掛けるかどうか。これなら選択肢がある
のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから(※1)
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
(自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない)
ほぼほぼの信頼度で実現できるというぐらい。
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.115s