例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。
> これはどういう意味なんだろうな。
そうそれ
tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう
0292デフォルトの名無しさん (ﾜｯﾁｮｲ e304-hmqi)2024/02/18(日) 14:01:41.78ID:6Yt/CDIt0
私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷
>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
悪魔の証明をテストすんのか
>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。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行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる
誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。
リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど
const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。
317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました
先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？
0326デフォルトの名無しさん (ﾜｯﾁｮｲ 67b1-Jq5A)2024/05/01(水) 21:36:46.68ID:/DCu7vsT0
python みたいに何でも格納できる辞書型ってC++には無いよね？
cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？
elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当
シェルが変だからな
case ～ esac
if ～ fi