俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな
ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな
お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。
ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに ＊想定し＊ プログラムを組まなくてはならない
さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか？
そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
（ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な（処理の）出発点に戻るという意味でもある）
起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ
C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。 たとえ綺麗な方法ではなくても。
どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。
> 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ
身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの
0283デフォルトの名無しさん (ﾜｯﾁｮｲ 1e85-XyAm)2024/02/17(土) 23:18:00.46ID:v62CV0mD0
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ 例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。
> これはどういう意味なんだろうな。
そうそれ
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++には無いよね？