C++相談室 part165

2023/10/31(火) 07:37:38.52

!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

2024/02/11(日) 09:47:48.61

アンカ間違えた、すまん
>>241は>>235宛な。

2024/02/11(日) 09:47:48.79

>>242
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか？
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う？

2024/02/11(日) 09:55:44.37

>>241
>>169を否定している
知らない例外が飛んできた場合にcatchして握りつぶしてそのまま動作を継続するかどうかって話な

2024/02/11(日) 10:07:06.72

>>244
バグのあるなしなんか関係ない設計の話だし、「例外はエラー伝達の具体的方法の一つ」って話のどこが抽象的なのかも分からないし、
「C++の現実」とか「カオス」が具体的に何のことで何の関係があるかも分からないし
STLにpopがないのはnoexcept moveがない時代に例外安全に出来なかったからだけど今の話に何の関係があるかわからないし
そんなのまともなC++erなら誰だって考えて設計してると思うけど、そうでないタコの話が何の関係あるかわからないし何もかも分からなすぎてすごい
仕事でそんなドキュメントやレビューコメント出すなよ

>>245
知らない例外を握り潰すのも、知らない戻り値をガン無視するのも一緒
errnoが変わってるのを無視するのもint*err引数に渡した変数の値を無視するのもexpected<T,E>で帰ってきたEを無視するのも「知らんエラーを無視した」という結果は一緒
知らんエラーを無視していいかどうかの意味論と、そのエラーがどう伝播して来るかかは関係ない
関係ない話を混ぜるからお前のC++はカオスなんだよ

2024/02/11(日) 10:14:56.00

>>245
？
そのtryブロックの処理が失敗したものとするって書いてあるじゃん。

2024/02/11(日) 11:18:37.96

>>231
>前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか
例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言
1. catchが書かれた関数が正しくcatchし、適切に処理するか（処理してせき止め　or/and 必要な場合再スロー)（←要テスト！
2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！

2をテストもせずに放置するとおかしくなる例は>>183のとうーり
これにより、例外を生じる関数foo()の呼び出しﾊﾟﾃｨｰﾝn個それぞれに対し、a個のテストが必要になっる
例外を発生させない使い方をするなら、n*a*mではなくmの定数倍（例外を飛ばさない使い方に依存擦る定数）。
例外が飛んで来たらバグ。わかりやすい

例外を多用しつつn*a*mをよくわからない計算とか言っている時点で以下略

2024/02/11(日) 11:18:50.45

>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228　例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
　　（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
　　結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある（>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
　　正常な動作の継続を意図する場合はテストケースが爆発する(>>

設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ；；；

いっぽう藻前らの主張は
1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
　（←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……

2024/02/11(日) 12:01:58.52

>>248
>例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言

やっぱり意味不明だな。catchすれば「階層をぶち抜いて」ってことはないわけだが。

>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！

もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
呼び出し階層全部でテストをしなきゃならないってことになるが。

2024/02/11(日) 12:31:22.40

>>249
>1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼

なるほどな。
catchする⇒無視する、握りつぶす　って脳内変換されてんだな。

catch書いたからといって上に挙げられたようなテストができなくなるわけじゃないっしょ。必要と思うならやればいい。

3.の意図しない例外の原因調査なんて main() に例外が上がってきてプログラムが落ちてからより
発生個所に近い下層で catch できた方がはるかに調査しやすいと思うんだがな。感覚が違うなあ。

2024/02/11(日) 12:37:47.91

仕様書や規格書はその意図を正確に読み取ろうとするのに
掲示板の他人の書き込みは積極的に曲解しようとするのは何故か？

2024/02/11(日) 12:44:06.42

見下しているからよ
こいつらは俺より下なはずと

2024/02/12(月) 07:49:39.70

本気で面白いと思ってやってんだろう

2024/02/12(月) 08:44:56.68

例外は糞！危険！意味不明！テスト漏れる！って言ってる奴ほど
if (err != 0) { return -1; }が大好きなんだよな
本質的にやってること変わらないのに

2024/02/12(月) 15:42:15.86

ファイル名に年月が使えないの困ります。
2024/02/11_データ.txt
とか

2024/02/12(月) 15:46:00.47

>>256
それ検索性最悪だから良くないんだよなぁ。
データ/2024/02/11/データ.txt
データ.txt/2024/02/11/データ.txt
あたりならまだ許せる。

2024/02/12(月) 16:40:43.94

ふつう年月日はハイフンで区切るよね

2024/02/12(月) 17:02:03.84

スラッシュを使う習慣が悪いわけではないが
プログラマの感覚だと ISO 8601 の方式に馴染みが有ることが多いってのはある。

2024/02/12(月) 17:31:20.60

年月日は「ふつう」がないのでみんなが苦労している
日本とアメリカとイギリスで順番が違うし
日本には「令和」とかあるし

2024/02/12(月) 18:43:50.33

Windowsでも / をディレクトリ区切り文字として使えるけど(場面は限定的かもしれないけど)、その認識で使ってるのかな…

2024/02/12(月) 20:07:00.91

Linux で * という名前のファイルを消そうとして
うわあぁぁぁとなった話はたまに聞く。
使えたとしても使うべきでない文字もある。

2024/02/12(月) 21:44:07.99

262>>
それ以外のファイルをすべて退避した上でディレクトリごと削除したことがあったな

2024/02/12(月) 21:46:10.68

すみません、261ですが、Windows限定の話ではなかったですね
失礼しました…

2024/02/13(火) 05:53:49.07

Linuxならi-nodeをしていすれば
findと組み合わせてどんな名前のファイルも消去できるんだけどなあ

windowsはなんか複雑だったような気がした

2024/02/13(火) 09:36:03.89

iso8901にしない人はたぶんこの規格を知らないわけで意識低すぎだろと思ってしまう

2024/02/13(火) 11:18:57.32

>>266
ISO 8901 は情報交換用 (要するに機械同士のやり取り) の時刻フォーマットを定める規格であって
言葉や文章で使うもの (人間が読み書きする目的) ではないと適用範囲の言及がある。
ファイル名はどちらの用途もありうるので >>256 がどのような状況を想定しているかによって
ISO 8901 が適切かどうかは違う。

もし非技術者向けのシステムなら
文化固有の日付表現に対応できてないほうが意識低いという見方もある。

2024/02/13(火) 12:55:27.90

>>267
エンドユーザーの文化的背景に配慮したデータフォーマットの利点は、エンドユーザーの知識やメタファーを利用した学習曲線の低勾配化であって、技術的には負の遺産になりやすいことには注意が必要。

典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
あるいは大きな桁から始まるバイト列とか。あんなの１桁目から始めればエンディアン問題とか無かった。

2024/02/13(火) 13:07:38.28

> 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
それは人間から見たときと機械から見たときの見やすさの違いでしかないような気がする

でも日本の住所は大きい方から始まるんだよな
アメリカは個人から始まる
文化の違いやけども、日本人は機械生命体だったのかもしれぬ

2024/02/15(木) 04:22:25.92

>>58
亀だがクロスで使ってるよ

2024/02/16(金) 22:41:08.10

enable_shared_from_thisなクラスで、shared_from_this()はコンストラクタの中では
呼べないようですね
コンストラクタの中の処理でthisを渡したい処理があるのですが、どうしたら...
そもそもそれ自体が間違っているのでしょうか
コンストラクタが呼ばれる行の次でその処理を呼べばいいという説もありますが、
現在のコードがそれをやりにくい形になっていて

2024/02/17(土) 11:55:24.05

>>250
>>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋

原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

>>251
>catchする⇒無視する、握りつぶす　って脳内変換
脳内変換ではなくて、予防的に入れたtry { } catch ()部分のテストが不十分な限り事実じゃーん？

>>252
>本質的にやってること変わらないのに
別に。
return -1; は呼び出し側のバグで見落とすかもしれないが
throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
むしろ予防的なtry { } catch () が例外のメリットをreturn -1; に縮小してゐる

2024/02/17(土) 12:01:54.73

>>253
藻前が二の句をつげないのは藻前の見識と資質の問題であって
漏れの責任ではないのでお間違えなきよう、
なのですよ……

2024/02/17(土) 12:35:51.03

テストって想定した動作環境、データ入力に対して想定した動作をするか確認をするわけで
想定しえないエラーや割り込みに対してはテストのしようがないんだけどな
そのための例外処理だろ

2024/02/17(土) 13:04:42.05

例外が上がってくるってことはどこかで例外を投げてるってことだぞ。
問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。
想定してないなら例外送出すらできないよ。

その上で人間は大きいプログラムの全体を把握することは困難だし
機械的なチェックがしづらいという現実はあるって話だ。

2024/02/17(土) 13:33:26.89

アプリケーションを作っているのとOSを作っている人は別
それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか
アプリケーション開発者はそれらすべて想定できているとでも？
ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな

2024/02/17(土) 13:41:06.46

>>276
「把握することは困難」という現実の話もしてる。
想定してはいて、しかしそれが伝わってない。
コミュニケーションの問題、自動化の問題として捉えるべき。

2024/02/17(土) 13:56:12.85

俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな

ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな

お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。

ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに　＊想定し＊　プログラムを組まなくてはならない
さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか？

そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
（ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な（処理の）出発点に戻るという意味でもある）
起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ

2024/02/17(土) 15:09:15.47

C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。たとえ綺麗な方法ではなくても。

どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。

2024/02/17(土) 15:39:40.77

>>271
一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので
コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか
そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか

2024/02/17(土) 15:49:12.98

> 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ

身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの

2024/02/17(土) 20:37:07.00

>>272
>原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ。

>return -1; は呼び出し側のバグで見落とすかもしれないが
>throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ

戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。

リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。

2024/02/17(土) 23:18:00.46

>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに

それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ

2024/02/17(土) 23:48:07.59

例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。

2024/02/18(日) 00:24:49.13

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

2024/02/18(日) 09:00:09.02

>>269
そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。
少なくとも例外みたいに変なフローで飛んで来ないし。

2024/02/18(日) 09:39:44.00

ぶっちゃけ>>283がなに言ってるのかわからない

継続してそれが原因で？
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？
オブジェクトの状態が変わっているかも？
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か？
Topは０で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ

2024/02/18(日) 09:41:50.12

>>285
>例外の種類しか頭にないのか

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

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

これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。

2024/02/18(日) 12:27:32.99

> これはどういう意味なんだろうな。
そうそれ

tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう

2024/02/18(日) 12:28:39.34

もちょも　は　もっとも　の　まちがい

2024/02/18(日) 13:22:22.19

>>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ

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

こんなUIだすやつセンスの欠片もない

2024/02/18(日) 14:01:41.78

私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷

2024/02/18(日) 15:55:07.22

>>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある

2024/02/18(日) 16:26:47.97

>>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。

2024/02/18(日) 17:54:38.27

>>289
もちょカワイイよね

2024/02/18(日) 18:17:37.55

>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか

2024/03/02(土) 23:41:07.84

>>282
>相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか

で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……

2024/03/02(土) 23:49:37.41

>>284
例外安全というもののスコープに対して考察が足りていない

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

2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
（つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない

2024/03/02(土) 23:57:46.67

それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点

例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい

2024/03/03(日) 21:57:15.41

>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。

2024/03/03(日) 22:08:48.84

>>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの

2024/03/03(日) 22:31:19.01

>>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ

2024/03/04(月) 00:08:35.31

>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？

悪魔の証明をテストすんのか

2024/03/04(月) 07:57:02.63

>>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流

2024/03/04(月) 07:58:21.27

なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……

例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
（自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない）
ほぼほぼの信頼度で実現できるというぐらい。

2024/03/04(月) 07:59:55.02

（※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる

2024/03/04(月) 08:09:49.95

あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
　ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
　十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
　　....
} catch (std::exception& e) {
　　log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に……

2024/03/04(月) 08:50:22.67

> なんか予想外に低ﾚなレスポンスを寄越した>>299……

299はお前自身じゃないのか、と俺は思う

2024/03/04(月) 08:53:34.53

>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える

例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。

2024/03/04(月) 10:20:12.57

例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの

たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている）

2024/03/04(月) 10:23:14.03

10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる

2024/03/04(月) 12:10:26.04

誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。

2024/04/08(月) 15:38:53.52

std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？

https://cpprefjp.github.io/reference/initializer_list/initializer_list.html

2024/04/09(火) 12:13:11.96

どこのコピー?

2024/04/09(火) 12:52:21.68

リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど

2024/04/09(火) 15:22:07.81

>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。

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

あえてやるならこんな感じかな……。
https://wandbox.org/permlink/HStrLq8ddyC3tby2

2024/04/09(火) 20:10:25.18

とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。

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

https://wandbox.org/permlink/OIgKM2DTqvpGduRV

2024/04/09(火) 20:30:45.76

>>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます

2024/04/09(火) 21:45:08.71

>>317
templateは型が違うと全くの別物として処理するからだと思う

2024/04/09(火) 22:00:45.26

>>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a)

2024/04/10(水) 08:39:45.44

const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。

2024/04/11(木) 21:42:31.84

317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました

2024/04/14(日) 14:49:11.63

先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？

2024/04/14(日) 15:03:51.38

あるよ。 https://github.com/cplusplus/papers/issues?q=sort%3Aupdated-desc

2024/04/16(火) 00:50:18.09

>>323
https://www.reddit.com/r/cpp/comments/1bloatw/202403_tokyo_iso_c_committee_trip_report_third/

2024/05/01(水) 21:36:46.68

python みたいに何でも格納できる辞書型ってC++には無いよね？

2024/05/01(水) 22:29:05.62

>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。

2024/05/09(木) 20:23:09.67

https://cpprefjp.github.io/lang/cpp23/add_support_for_preprocessing_directives_elifdef_and_elifndef.html
#elifって今まで非標準だったのかよ…

2024/05/09(木) 21:19:14.71

何いってんだ

2024/05/10(金) 11:53:06.45

#elifは大昔からあるぞ

2024/05/11(土) 09:12:25.64

cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？

2024/05/11(土) 11:19:25.57

規格が読めないならC++やめろ

2024/05/11(土) 19:02:18.20

elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当

2024/05/11(土) 22:20:47.67

シェルが変だからな
case ～ esac
if ～ fi

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 07:08:30.09

てｓｔ

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 07:55:41.85

質問なのですが
Q1. std::fstreamでファイルを開くときのフラグの指定の仕方は次のどれが正義？
　std::fstream ofs("foo.txt", std::ios::out | std::ios::binary); // (1)
　std::fstream ofs("foo.txt", std::basic_ios::out | std::basic_ios::binary); // (2)
　std::fstream ofs("foo.txt", std::fstream::out | std::fstream::binary); // (3)

2024/06/06(木) 15:53:22.90

フル手書き前提がくそださい

2024/06/06(木) 19:13:19.37

fstreamなんだったらfstreamのメンバで書くのがいいんじゃない

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 23:36:07.51

(1)は#include <ios>が要るし、
(2)は「basic_」の6文字×フラグの数だけ長いし、
(3)も同様でありなおかつ>>337に従ったとき
　use binary = std::fstream::binary;
　use ibinary = std::ifstream::binary;
　use obinary = std::ofstream::binary;
となってしまい、
どれもこれもコード量最小化原則的にﾋﾞﾐｮｰなことに……

ていうかなんで同じことをするのに複数の書き方があるのかっていうか、
Perlじゃあるまいし……

2024/06/06(木) 23:54:13.70

iostreamはまあしゃーない…

2024/06/07(金) 02:20:24.96

C++の悪評の4割くらいはiostreamのせいだからな

2024/06/07(金) 04:24:11.05

ここでCmakeとNinjaについて聞くのダメ?
どーも関係がよくわからなくて?