C++相談室 part165

1 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ efda-9b8G) mailto:sage [2023/10/31(火) 07:37:38.52 ID:+ZyYyqMO0.net] !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 256 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:42:15.86 ID:NdUIQhSh0.net] ファイル名に年月が使えないの困ります。 2024/02/11_データ.txt とか 257 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:46:00.47 ID:QicyHe7E0.net] >>256 それ検索性最悪だから良くないんだよなぁ。 データ/2024/02/11/データ.txt データ.txt/2024/02/11/データ.txt あたりならまだ許せる。 258 名前：デフォルトの名無しさん [2024/02/12(月) 16:40:43.94 ID:MdmHk5EH0.net] ふつう年月日はハイフンで区切るよね 259 名前：はちみつ餃子 mailto:sage [2024/02/12(月) 17:02:03.84 ID:4VueJhli0.net] スラッシュを使う習慣が悪いわけではないが プログラマの感覚だと ISO 8601 の方式に馴染みが有ることが多いってのはある。 260 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 5edc-s3Gl) mailto:sage [2024/02/12(月) 17:31:20.60 ID:rGOG+Ewu0.net] 年月日は「ふつう」がないのでみんなが苦労している 日本とアメリカとイギリスで順番が違うし 日本には「令和」とかあるし 261 名前：デフォルトの名無しさん [2024/02/12(月) 18:43:50.33 ID:zGvIVge80.net] Windowsでも / をディレクトリ区切り文字として使えるけど(場面は限定的かもしれないけど)、その認識で使ってるのかな… 262 名前：はちみつ餃子 mailto:sage [2024/02/12(月) 20:07:00.91 ID:4VueJhli0.net] Linux で * という名前のファイルを消そうとして うわあぁぁぁとなった話はたまに聞く。 使えたとしても使うべきでない文字もある。 263 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f7cb-nOVH) mailto:sage [2024/02/12(月) 21:44:07.99 ID:zGvIVge80.net] 262>> それ以外のファイルをすべて退避した上でディレクトリごと削除したことがあったな 264 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f7cb-nOVH) mailto:sage [2024/02/12(月) 21:46:10.68 ID:zGvIVge80.net] すみません、261ですが、Windows限定の話ではなかったですね 失礼しました… 265 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 5edc-s3Gl) mailto:sage [2024/02/13(火) 05:53:49.07 ID:QIUviIGO0.net] Linuxならi-nodeをしていすれば findと組み合わせてどんな名前のファイルも消去できるんだけどなあ windowsはなんか複雑だったような気がした 266 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 09:36:03.89 ID:7CLA20rP0.net] iso8901にしない人はたぶんこの規格を知らないわけで意識低すぎだろと思ってしまう 267 名前：はちみつ餃子 mailto:sage [2024/02/13(火) 11:18:57.32 ID:T85IlqBy0.net] >>266 ISO 8901 は情報交換用 (要するに機械同士のやり取り) の時刻フォーマットを定める規格であって 言葉や文章で使うもの (人間が読み書きする目的) ではないと適用範囲の言及がある。 ファイル名はどちらの用途もありうるので >>256 がどのような状況を想定しているかによって ISO 8901 が適切かどうかは違う。 もし非技術者向けのシステムなら 文化固有の日付表現に対応できてないほうが意識低いという見方もある。 268 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:55:27.90 ID:c63MYIIQ0.net] >>267 エンドユーザーの文化的背景に配慮したデータフォーマットの利点は、エンドユーザーの知識やメタファーを利用した学習曲線の低勾配化であって、技術的には負の遺産になりやすいことには注意が必要。 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。 あるいは大きな桁から始まるバイト列とか。あんなの１桁目から始めればエンディアン問題とか無かった。 269 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:07:38.28 ID:mTl8FNrx0.net] > 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。 それは人間から見たときと機械から見たときの見やすさの違いでしかないような気がする でも日本の住所は大きい方から始まるんだよな アメリカは個人から始まる 文化の違いやけども、日本人は機械生命体だったのかもしれぬ 270 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 6b74-e92p) mailto:sage [2024/02/15(木) 04:22:25.92 ID:MOgQCM5N0.net] >>58 亀だがクロスで使ってるよ 271 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 22:41:08.10 ID:/bcZ41DF0.net] enable_shared_from_thisなクラスで、shared_from_this()はコンストラクタの中では 呼べないようですね コンストラクタの中の処理でthisを渡したい処理があるのですが、どうしたら... そもそもそれ自体が間違っているのでしょうか コンストラクタが呼ばれる行の次でその処理を呼べばいいという説もありますが、 現在のコードがそれをやりにくい形になっていて 272 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:55:24.05 ID:hsYxYbKj0.net] >>250 >>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！ >もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する >呼び出し階層全部でテストをしなきゃならないってことになるが。 その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋 原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい >>251 >catchする⇒無視する、握りつぶす　って脳内変換 脳内変換ではなくて、予防的に入れたtry { } catch ()部分のテストが不十分な限り事実じゃーん？ >>252 >本質的にやってること変わらないのに 別に。 return -1; は呼び出し側のバグで見落とすかもしれないが throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ むしろ予防的なtry { } catch () が例外のメリットをreturn -1; に縮小してゐる 273 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:01:54.73 ID:hsYxYbKj0.net] >>253 藻前が二の句をつげないのは藻前の見識と資質の問題であって 漏れの責任ではないのでお間違えなきよう、 なのですよ…… 274 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:35:51.03 ID:mUyTgSzm0.net] テストって想定した動作環境、データ入力に対して想定した動作をするか確認をするわけで 想定しえないエラーや割り込みに対してはテストのしようがないんだけどな そのための例外処理だろ 275 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 13:04:42.05 ID:4+T7+QKn0.net] 例外が上がってくるってことはどこかで例外を投げてるってことだぞ。 問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。 想定してないなら例外送出すらできないよ。 その上で人間は大きいプログラムの全体を把握することは困難だし 機械的なチェックがしづらいという現実はあるって話だ。 276 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 13:33:26.89 ID:mUyTgSzm0.net] アプリケーションを作っているのとOSを作っている人は別 それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか アプリケーション開発者はそれらすべて想定できているとでも？ ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな 277 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 13:41:06.46 ID:4+T7+QKn0.net] >>276 「把握することは困難」という現実の話もしてる。 想定してはいて、しかしそれが伝わってない。 コミュニケーションの問題、自動化の問題として捉えるべき。 278 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 13:56:12.85 ID:mUyTgSzm0.net] 俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな お前自身がこう言っている > その上で人間は大きいプログラムの全体を把握することは困難だし > 機械的なチェックがしづらいという現実はあるって話だ。 ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか アプリケーション開発者はその公開情報をもとに　＊想定し＊　プログラムを組まなくてはならない さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか？ そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに （ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な（処理の）出発点に戻るという意味でもある） 起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ 279 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 6332-A7R9) mailto:sage [2024/02/17(土) 15:09:15.47 ID:4+T7+QKn0.net] C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という 状況に対処する方法があることも大事にしてはいる。 たとえ綺麗な方法ではなくても。 どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、 それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、 想定が不十分でも構わないという話でもない。 よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。 280 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 15:39:40.77 ID:snTd9S980.net] >>271 一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか 281 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 15:49:12.98 ID:mUyTgSzm0.net] > 想定が不十分でも構わないという話でもない。 誰もそれで構わないとは言っていないので それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ 身も蓋もない言い方をするなら そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない （もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている） アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの 282 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC) mailto:sage [2024/02/17(土) 20:37:07.00 ID:QSMcEn770.net] >>272 >原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい 相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ。 >return -1; は呼び出し側のバグで見落とすかもしれないが >throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ 戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。 リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。 283 名前：デフォルトの名無しさん [2024/02/17(土) 23:18:00.46 ID:v62CV0mD0.net] >>278 > そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて > どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに それは幻想 c++の例外安全の達成がどれだけ難しいか理解していないね 簡単にリークするし、オブジェクトが想定外の状態を持ったりする 動作保証ができない だから仕様に明示されていない例外が来たら基本は終了だよ そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ 284 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 23:48:07.59 ID:QSMcEn770.net] 例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。 285 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 00:24:49.13 ID:JX7gxI3D0.net] >>284 例外の種類しか頭にないのか 任意の場所での例外発生に対応するなん現実的にできないということ 286 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:00:09.02 ID:c1Urupub0.net] >>269 そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。 少なくとも例外みたいに変なフローで飛んで来ないし。 287 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:39:44.00 ID:9f8IS57r0.net] ぶっちゃけ>>283がなに言ってるのかわからない 継続してそれが原因で？ いやいやw 突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？ オブジェクトの状態が変わっているかも？ 変更前のデータと比較して変わっていたらユーザに確認すればいいだろ 例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か？ Topは０で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ 288 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:41:50.12 ID:WHoJTRhT0.net] >>285 >例外の種類しか頭にないのか >>283が仕様に明示されていない例外を話題にしているからだが。 >任意の場所での例外発生に対応するなん現実的にできないということ これはどういう意味なんだろうな。 着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって それは基本的に局所的に判断できるもの。 下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。 289 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7) mailto:sage [2024/02/18(日) 12:27:32.99 ID:9f8IS57r0.net] > これはどういう意味なんだろうな。 そうそれ tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか 想定している例外が発生して継続できると判断したなら続ければいいし ダメならユーザに通知してもちょも安全な方法を選択させればいい でもってそれは想定していない例外の発生でも同じ ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう 290 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7) mailto:sage [2024/02/18(日) 12:28:39.34 ID:9f8IS57r0.net] もちょも　は　もっとも　の　まちがい 291 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 6f5b-ERL4) mailto:sage [2024/02/18(日) 13:22:22.19 ID:JX7gxI3D0.net] >>287 ファイル保存するなとか言ってない それぐらい終了処理のひとつだろ ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ 意味不明な例外が発生しました データが破損してないかあなたが確認してください 動作無保証ですが処理継続しますか？yes/no こんなUIだすやつセンスの欠片もない 292 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ e304-hmqi) [2024/02/18(日) 14:01:41.78 ID:6Yt/CDIt0.net] 私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷 293 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 15:55:07.22 ID:1iQutSwY0.net] >>291 それを思いついたお前のセンスがないと言うことになるが… 俺は確認しろと言っただけだし確認には様々な方法がある 294 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 16:26:47.97 ID:WHoJTRhT0.net] >>291 まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。 295 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 17:54:38.27 ID:L2mk1x1ad.net] >>289 もちょカワイイよね 296 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 18:17:37.55 ID:LeQ06zof0.net] >>280 実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに 連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる やはり引越し作業完了を待ってからの方がいいのか。ってちがうか 297 名前：デフォルトの名無しさん mailto:sage [2024/03/02(土) 23:41:07.84 ID:C77pR/Zl0.net] >>282 >相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ >249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは 確定的に明らか で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである 普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。 try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ…… 298 名前：デフォルトの名無しさん mailto:sage [2024/03/02(土) 23:49:37.41 ID:C77pR/Zl0.net] >>284 例外安全というもののスコープに対して考察が足りていない 1. 例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、 システム全体については>>283の通りであって全然安全ではない 2. fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について 全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。 （つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない 299 名前：デフォルトの名無しさん mailto:sage [2024/03/02(土) 23:57:46.67 ID:C77pR/Zl0.net] それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点 例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る （例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等） のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい 300 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 0fcf-0WZ8) mailto:sage [2024/03/03(日) 21:57:15.41 ID:735dldsp0.net] >>298 自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。 しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという 変な決めつけが混じってる。 例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない なんてのはそもそも例外安全とは言わない。 301 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ef0a-qSkN) mailto:sage [2024/03/03(日) 22:08:48.84 ID:qMaLplcd0.net] >>300 お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？ それが出来もしない理想論だって言ってんの 302 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 3b7c-85wQ) mailto:sage [2024/03/03(日) 22:31:19.01 ID:GdJ/jhkt0.net] >>301 自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ 303 名前：デフォルトの名無しさん mailto:sage [2024/03/04(月) 00:08:35.31 ID:gWJ01aQ50.net] >お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？ 悪魔の証明をテストすんのか 304 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ef0a-qSkN) mailto:sage [2024/03/04(月) 07:57:02.63 ID:D3yk9beu0.net] >>302 100%自分で書いてるコードなら未知の例外なんて起こらんだろ 話の筋理解してからレスつけろや三流 305 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD) mailto:sage [2024/03/04(月) 07:58:21.27 ID:KYG2Ugpe0.net] なんか予想外に低ﾚなレスポンスを寄越した>>299…… さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか…… 例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、 中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、 >>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1） >>284が空想するようなシステム全体の例外安全化などは現実には不可能。 せいぜいある程度の規模のオブジェクトであれば、十分テストすれば （自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない） ほぼほぼの信頼度で実現できるというぐらい。 306 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD) mailto:sage [2024/03/04(月) 07:59:55.02 ID:KYG2Ugpe0.net] （※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる 307 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD) mailto:sage [2024/03/04(月) 08:09:49.95 ID:KYG2Ugpe0.net] あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので （直接そういうのをやってちるわけではないので強くは言わんが 　ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、 　十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする try { 　　.... } catch (std::exception& e) { 　　log_e("std::exceptionがスローされました"); }; みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない 100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら >>282は自○が真剣に考慮すべき選択肢に…… 308 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9fad-ZLJX) mailto:sage [2024/03/04(月) 08:50:22.67 ID:MzjtGtOW0.net] > なんか予想外に低ﾚなレスポンスを寄越した>>299…… 299はお前自身じゃないのか、と俺は思う 309 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 0fcf-0WZ8) mailto:sage [2024/03/04(月) 08:53:34.53 ID:gWJ01aQ50.net] >例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば >その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える 例外安全だからといってcatchが不要になるわけないだろ。 根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。 310 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-XE6S) [2024/03/04(月) 10:20:12.57 ID:QvxlWFfk0.net] 例外安全には基本保証・強い保証・no-fail保証がある 例外がスローされない関数を作ればno-fail保証がある 基本保証や強い保証は例外発生後も不整合が発生しないもの たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている） 311 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-XE6S) [2024/03/04(月) 10:23:14.03 ID:QvxlWFfk0.net] 10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない 例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる 312 名前：はちみつ餃子 mailto:sage [2024/03/04(月) 12:10:26.04 ID:ASLjljy+0.net] 誤解のないように念のため補足。 この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？) 例外を出さずに済むならそれに越したことはないよ。 でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。 連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。 仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。 313 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 15:38:53.52 ID:IvxniXPw0.net] std::initializer_listについて質問です 下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？ これは無駄なので回避したいのですが良い方法はありますか？ https://cpprefjp.github.io/reference/initializer_list/initializer_list.html 314 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ df01-g9Lk) mailto:sage [2024/04/09(火) 12:13:11.96 ID:gepNgOiE0.net] どこのコピー? 315 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM3e-Nnmc) mailto:sage [2024/04/09(火) 12:52:21.68 ID:80QuF/MqM.net] リテラルのコピーを気にするならconstexprじゃねーの？ ほんとにコンパイル時に定数になるかは知らんけど 316 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 15:22:07.81 ID:hsAXyuRl0.net] >>313 C++ に配列リテラルはない。 その書き方で出てくる波括弧はリスト初期化の構文の一部で、 波括弧の部分単体は配列リテラルではない。 実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが それはそれで色々と制約があるんでほんまにそれが必要なんか？ というのはよく考えないといけない。 あえてやるならこんな感じかな……。 https://wandbox.org/permlink/HStrLq8ddyC3tby2 317 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 20:10:25.18 ID:T/amOWJO0.net] とあるtemplateの関数を実装しているのですが、 const指定の振る舞いがよくわからなくなったので 質問させてください。 以下の(だいぶ簡略化した)コードで、 f_without_const<const int*>(const int* a) はコンパイルが通るのですが f_with_const<int*>(const int* a) がコンパイルが通らないのは何故でしょうか。 https://wandbox.org/permlink/OIgKM2DTqvpGduRV 318 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 20:30:45.76 ID:lDhzon+/0.net] >>316 なるほど ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます 319 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 21:45:08.71 ID:+RmfoJzl0.net] >>317 templateは型が違うと全くの別物として処理するからだと思う 320 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 22:00:45.26 ID:5hAg3cgl0.net] >>317 template <class T> void f_with_const (const T t); これに対応させるなら f_with_const<int*>(int *const a) 321 名前：はちみつ餃子 mailto:sage [2024/04/10(水) 08:39:45.44 ID:Fk7YBwaR0.net] const T t に対して const int* a が来たら 字句の順序としては T に int* が対応してるように見えちゃうもんな……。 322 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:42:31.84 ID:0cjrPM+u0.net] 317です、返信遅くなってすみません 確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね… ありがとうございました 323 名前：デフォルトの名無しさん mailto:sage [2024/04/14(日) 14:49:11.63 ID:tTNkn9kB0.net] 先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？ 324 名前：デフォルトの名無しさん mailto:sage [2024/04/14(日) 15:03:51.38 ID:H7y3imqp0.net] あるよ。 https://github.com/cplusplus/papers/issues?q=sort%3Aupdated-desc 325 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7f52-9wFU) mailto:sage [2024/04/16(火) 00:50:18.09 ID:38VQ+8UT0.net] >>323 https://www.reddit.com/r/cpp/comments/1bloatw/202403_tokyo_iso_c_committee_trip_report_third/ 326 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 67b1-Jq5A) [2024/05/01(水) 21:36:46.68 ID:/DCu7vsT0.net] python みたいに何でも格納できる辞書型ってC++には無いよね？ 327 名前：はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ 8732-nVjz) mailto:sage [2024/05/01(水) 22:29:05.62 ID:IV4TsWNk0.net] >>326 要素を std::any にすればだいたいどんな型の値でも入れられる。 いろんな型を入れたところで使うときには元の型として取り出さないといけないから 処理は煩雑になってあまり良いことはないけど。 328 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8f7c-Y/5H) mailto:sage [2024/05/09(木) 20:23:09.67 ID:MzADiHDk0.net] https://cpprefjp.github.io/lang/cpp23/add_support_for_preprocessing_directives_elifdef_and_elifndef.html #elifって今まで非標準だったのかよ… 329 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ bed6-w0ma) mailto:sage [2024/05/09(木) 21:19:14.71 ID:M6C6+6vz0.net] 何いってんだ 330 名前：デフォルトの名無しさん mailto:sage [2024/05/10(金) 11:53:06.45 ID:P+BretyD0.net] #elifは大昔からあるぞ 331 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 09:12:25.64 ID:YR9R4Y390.net] cpprefjpが間違ってるだけ？ それともずっと規格から欠落してたけど誰も気付いてなかったパターン？ 332 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 11:19:25.57 ID:PrWZroBw0.net] 規格が読めないならC++やめろ 333 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 0b63-IWIS) mailto:sage [2024/05/11(土) 19:02:18.20 ID:RotYKdRC0.net] elifを逆から読んだらfile ラリーはこれを嫌ってPerlではelsifにした（適当 334 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 22:20:47.67 ID:HBPowvO20.net] シェルが変だからな case ～ esac if ～ fi 335 名前： mailto:sage [2024/06/06(木) 07:08:30.09 ID:Glzej5210.net] てｓｔ 336 名前： mailto:sage [2024/06/06(木) 07:55:41.85 ID:Glzej5210.net] 質問なのですが 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) 337 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMde-FHn0) mailto:sage [2024/06/06(木) 15:53:22.90 ID:Vp529NVwM.net] フル手書き前提がくそださい 338 名前：デフォルトの名無しさん mailto:sage [2024/06/06(木) 19:13:19.37 ID:FMMlTunO0.net] fstreamなんだったらfstreamのメンバで書くのがいいんじゃない 339 名前： mailto:sage [2024/06/06(木) 23:36:07.51 ID:Glzej5210.net] (1)は#include <ios>が要るし、 (2)は「basic_」の6文字×フラグの数 だけ長いし、 (3)も同様でありなおかつ>>337に従ったとき 　use binary = std::fstream::binary; 　use ibinary = std::ifstream::binary; 　use obinary = std::ofstream::binary; となってしまい、 どれもこれもコード量最小化原則的にﾋﾞﾐｮｰなことに…… ていうかなんで同じことをするのに複数の書き方があるのかっていうか、 Perlじゃあるまいし…… 340 名前：デフォルトの名無しさん mailto:sage [2024/06/06(木) 23:54:13.70 ID:7ZzCG2hU0.net] iostreamはまあしゃーない… 341 名前：デフォルトの名無しさん mailto:sage [2024/06/07(金) 02:20:24.96 ID:GhXFHGen0.net] C++の悪評の4割くらいはiostreamのせいだからな 342 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ a944-l7CW) mailto:sage [2024/06/07(金) 04:24:11.05 ID:qf+nnTv50.net] ここでCmakeとNinjaについて聞くのダメ? どーも関係がよくわからなくて? 343 名前：はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG) mailto:sage [2024/06/07(金) 05:26:04.94 ID:zM43Xr/H0.net] >>342 そういう雑多な話題のちょうどよいスレは見当たらんし、単発で終わる質問程度なら許容されると思うが……。 質問の内容が漠然としているなら丁寧な回答は得られないと思う。 「よくわからない」という状況になるときってのは大抵の場合に関連する前提知識が足りてないので 質問が連鎖的に発生してダラダラ続いたりするから。 344 名前：はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG) mailto:sage [2024/06/07(金) 05:36:24.41 ID:zM43Xr/H0.net] >>336 第四の選択肢 std::fstream ofs("foo.txt", ofs.out | ofs.binary); 345 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ fee5-FHn0) mailto:sage [2024/06/07(金) 13:37:29.47 ID:kav19u0f0.net] copilotで補完でok 346 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 6af0-AYul) mailto:sage [2024/06/07(金) 17:07:58.06 ID:NFmVQMC40.net] バカの解決策 347 名前：デフォルトの名無しさん mailto:sage [2024/06/07(金) 21:12:45.28 ID:70o6R+hDM.net] また時代に取り残されるじじい 348 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-WQ8n) mailto:sage [2024/06/07(金) 21:48:19.45 ID:ORLoeNdF0.net] >>344 ofsのスコープの隙間を突きなおかつ静的メンバをドット演算子で参照する等 テクニカルですばらっし 349 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 01:03:51.86 ID:k3Jnk/Aj0.net] 静的解析で文句言われる可能性あるからやめときな 頻発するならスニペット作ればいいだけ そういう表面的なことにこだわる奴は三流 350 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF) mailto:sage [2024/06/09(日) 04:26:59.39 ID:RJYm8+UN0.net] lldb v14.0.0 で正しくプロセスを実行できません apt insrall でインストールしたもので, 環境はwsl 1 です 具体的には下のサイトのIssue Encountered:と全く同じ症状です https://stackoverflow.com/questions/78275920/troubleshoot-lldb-on-ubuntu-wsl 改めて書きますと Hello World 表示だけのソースを clang でコンパイルし, lldb で読み込み run させると Process 20784 launched: '/home/Hustler/c++/move/move' (x86_64) と表示されたまま応答がなくなり 放置すると(サイトでは強制終了させてるようですが) Process 20784 exited with status = -1 (0xffffffff) lost connection となってコマンド入力待ち状態となります ちなみにプログラムはそのまま実行して正しく動作しますし gdb でも何の問題もありません これに関して何か情報をお持ちの方いますか? 351 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF) mailto:sage [2024/06/09(日) 05:11:57.08 ID:RJYm8+UN0.net] 今やってみたのですが lldb-14をuninstall(remove)し lldb-15をインストールしてみましたが 状況は改善しませんでした 352 名前：はちみつ餃子 mailto:sage [2024/06/09(日) 15:07:14.43 ID:bthWHIYm0.net] WSL1 は (ある程度) Linux 互換のシステムコールを windows 内に実装することで実現していて Linux カーネルそのものではないので色々と不足がある。 (そのかわり Windows と親和性がある部分もある。) WSL1 で用意してない Linux の機能に依存したアプリケーションは動かない。 まともな互換性が必要ならWSL2 を使いなさいという話なので手間をかけて WSL1 を積極的にはサポートしないと思う。 353 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF) mailto:sage [2024/06/09(日) 20:56:05.63 ID:RJYm8+UN0.net] >>352 wsl2 ではlldbは問題なく動いてるんですか? 古いCPUなのでwsl2がインスコできないもんで 上のサイトはwslのバージョンは書いてなかったようですし 354 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 6363-vt9G) mailto:sage [2024/06/09(日) 21:14:14.41 ID:VES2dE5O0.net] WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと ターゲット機を別にするとかWSL2にするとかじゃね？ 355 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF) mailto:sage [2024/06/09(日) 21:36:35.88 ID:RJYm8+UN0.net] >>354 >WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと なるほどTHXです clang使ってなかったので全然わかりませんでした 動かないlldbもさんざんggったんだけど system call未実装にはたどり着けませんでした ようやくすっきりしました 356 名前：はちみつ餃子 mailto:sage [2024/06/09(日) 22:04:05.34 ID:bthWHIYm0.net] ざっとググってみた感じたと wsl1 では procfs が提供する情報が少ないのが lldb が動かない直接の原因みたいな数年前の情報は見つかる。 内部構造がまるで違うはずなのに表面的なインターフェースは互換にするなんてのは無理のある話なので互換性が「ある程度」にとどまるのは仕方ない。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef