C++相談室 part165
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること
次スレは>>980が立てること
無理なら細かく安価指定
※前スレ
C++相談室 part164
https://mevius.5ch.net/test/read.cgi/tech/1683600652/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 例外が上がってくるってことはどこかで例外を投げてるってことだぞ。
問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。
想定してないなら例外送出すらできないよ。
その上で人間は大きいプログラムの全体を把握することは困難だし
機械的なチェックがしづらいという現実はあるって話だ。 アプリケーションを作っているのとOSを作っている人は別
それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか
アプリケーション開発者はそれらすべて想定できているとでも？
ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな >>276
「把握することは困難」という現実の話もしてる。
想定してはいて、しかしそれが伝わってない。
コミュニケーションの問題、自動化の問題として捉えるべき。 俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな
ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな
お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。
ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに ＊想定し＊ プログラムを組まなくてはならない
さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか？
そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
（ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な（処理の）出発点に戻るという意味でもある）
起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。 たとえ綺麗な方法ではなくても。
どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。 >>271
一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので
コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか
そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか > 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ
身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの >>272
>原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい
相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ。
>return -1; は呼び出し側のバグで見落とすかもしれないが
>throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。
リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。 >>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ 例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。 >>284
例外の種類しか頭にないのか
任意の場所での例外発生に対応するなん現実的にできないということ >>269
そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。
少なくとも例外みたいに変なフローで飛んで来ないし。 ぶっちゃけ>>283がなに言ってるのかわからない
継続してそれが原因で？
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？
オブジェクトの状態が変わっているかも？
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か？
Topは０で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ >>285
>例外の種類しか頭にないのか
>>283が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。 > これはどういう意味なんだろうな。
そうそれ
tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう >>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ
意味不明な例外が発生しました
データが破損してないかあなたが確認してください
動作無保証ですが処理継続しますか？yes/no
こんなUIだすやつセンスの欠片もない 私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷 >>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある >>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。 >>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか >>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか
で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ…… >>284
例外安全というもののスコープに対して考察が足りていない
1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない
2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
（つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい >>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。 >>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの >>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ >お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
悪魔の証明をテストすんのか >>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流 なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……
例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
（自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない）
ほぼほぼの信頼度で実現できるというぐらい。 （※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
....
} catch (std::exception& e) {
log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に…… > なんか予想外に低ﾚなレスポンスを寄越した>>299……
299はお前自身じゃないのか、と俺は思う >例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。 例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの
たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている） 10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる 誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。 std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？
https://cpprefjp.github.io/reference/initializer_list/initializer_list.html リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど >>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。
実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか？
というのはよく考えないといけない。
あえてやるならこんな感じかな……。
https://wandbox.org/permlink/HStrLq8ddyC3tby2 とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。
以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
がコンパイルが通らないのは何故でしょうか。
https://wandbox.org/permlink/OIgKM2DTqvpGduRV >>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます >>317
templateは型が違うと全くの別物として処理するからだと思う >>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a) const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。 317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました 先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？ 
