X



C++相談室 part165
0287デフォルトの名無しさん (ワッチョイ e3f9-NGC7)
垢版 |
2024/02/18(日) 09:39:44.00ID:9f8IS57r0
ぶっちゃけ>>283がなに言ってるのかわからない

継続してそれが原因で?
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ?
オブジェクトの状態が変わっているかも?
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か?
Topは0で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ
0288デフォルトの名無しさん (ワッチョイ cfcf-sYtR)
垢版 |
2024/02/18(日) 09:41:50.12ID:WHoJTRhT0
>>285
>例外の種類しか頭にないのか

>>283が仕様に明示されていない例外を話題にしているからだが。

>任意の場所での例外発生に対応するなん現実的にできないということ

これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。
0289デフォルトの名無しさん (ワッチョイ e3f9-NGC7)
垢版 |
2024/02/18(日) 12:27:32.99ID:9f8IS57r0
> これはどういう意味なんだろうな。
そうそれ

tryブロックで囲った部分(つまり任意)の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう
0291デフォルトの名無しさん (ワッチョイ 6f5b-ERL4)
垢版 |
2024/02/18(日) 13:22:22.19ID:JX7gxI3D0
>>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ

意味不明な例外が発生しました
データが破損してないかあなたが確認してください
動作無保証ですが処理継続しますか?yes/no

こんなUIだすやつセンスの欠片もない
0292デフォルトの名無しさん (ワッチョイ e304-hmqi)
垢版 |
2024/02/18(日) 14:01:41.78ID:6Yt/CDIt0
私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷
0296デフォルトの名無しさん (ワッチョイ bf9a-/DPD)
垢版 |
2024/02/18(日) 18:17:37.55ID:LeQ06zof0
>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか
0297デフォルトの名無しさん (ワッチョイ 1b63-9XlH)
垢版 |
2024/03/02(土) 23:41:07.84ID:C77pR/Zl0
>>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか

で、例外というブツは「例外なく」悪い知らせなので(∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように(可能な限り)修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……
0298デフォルトの名無しさん (ワッチョイ 1b63-9XlH)
垢版 |
2024/03/02(土) 23:49:37.41ID:C77pR/Zl0
>>284
例外安全というもののスコープに対して考察が足りていない

1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は(メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない

2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
(つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない
0299デフォルトの名無しさん (ワッチョイ 1b63-9XlH)
垢版 |
2024/03/02(土) 23:57:46.67ID:C77pR/Zl0
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点

例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
(例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等)
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというアフォはやっぱtry { } catch () しないのが正しい
0300デフォルトの名無しさん (ワッチョイ 0fcf-0WZ8)
垢版 |
2024/03/03(日) 21:57:15.41ID:735dldsp0
>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。
0305デフォルトの名無しさん (ワッチョイ 8b63-eOBD)
垢版 |
2024/03/04(月) 07:58:21.27ID:KYG2Ugpe0
なんか予想外に低レなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……

例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる(処理の順序が命)というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから(※1)
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
(自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない)
ほぼほぼの信頼度で実現できるというぐらい。
0307デフォルトの名無しさん (ワッチョイ 8b63-eOBD)
垢版 |
2024/03/04(月) 08:09:49.95ID:KYG2Ugpe0
あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
(直接そういうのをやってちるわけではないので強くは言わんが
 ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
 十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
  ....
} catch (std::exception& e) {
  log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に……
0309デフォルトの名無しさん (ワッチョイ 0fcf-0WZ8)
垢版 |
2024/03/04(月) 08:53:34.53ID:gWJ01aQ50
>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える

例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。
0310デフォルトの名無しさん (ワッチョイ abe4-XE6S)
垢版 |
2024/03/04(月) 10:20:12.57ID:QvxlWFfk0
例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの

たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない(おそらく実行中フラグ変数が立ったままになっている)
0311デフォルトの名無しさん (ワッチョイ abe4-XE6S)
垢版 |
2024/03/04(月) 10:23:14.03ID:QvxlWFfk0
10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある(例外安全である)といえる
0312はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 3b32-hL5K)
垢版 |
2024/03/04(月) 12:10:26.04ID:ASLjljy+0
誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね?)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。
0316デフォルトの名無しさん (ワッチョイ 7b32-B3tP)
垢版 |
2024/04/09(火) 15:22:07.81ID:hsAXyuRl0
>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。

実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか?
というのはよく考えないといけない。

あえてやるならこんな感じかな……。
https://wandbox.org/permlink/HStrLq8ddyC3tby2
0317デフォルトの名無しさん (ワッチョイ c3c9-hAMa)
垢版 |
2024/04/09(火) 20:10:25.18ID:T/amOWJO0
とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。

以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
がコンパイルが通らないのは何故でしょうか。

https://wandbox.org/permlink/OIgKM2DTqvpGduRV
0326デフォルトの名無しさん (ワッチョイ 67b1-Jq5A)
垢版 |
2024/05/01(水) 21:36:46.68ID:/DCu7vsT0
python みたいに何でも格納できる辞書型ってC++には無いよね?
0327はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 8732-nVjz)
垢版 |
2024/05/01(水) 22:29:05.62ID:IV4TsWNk0
>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。
レスを投稿する


ニューススポーツなんでも実況