C++相談室 part165
!extend:checked:vvvvv:1000:512 >>980 が立てること https://mevius.5ch.net/test/read.cgi/tech/1683600652/ てきました㌧クス、 C++23だとこれ PythonやC#のようなf"{x}"構文が作られる事はないんだろうか >>85 質問なのですが自作クラスFooのストリーム出力演算子に引数付きのマニピュレータを追加したいのですが グローバル変数渡しは最初に思いつくのですが、ostringstream os1, os2とFoo obj1, obj2に対して異なるスレッドで >>87-88 既存のcoutとかstringstreamとかで使いたいなら、グローバルのstd::unordered_map<std::ios_base*, MyManipData>にでも置いとくしかないだろうね レス㌧クス、 // 使い方 ストリーム用の演算子なんか作らずに Foo obj; C++20 からは std::formatter を特殊化して書式指定を解釈するコードを入れておけば オブジェクトの文字列表現が10億ギガ文字もあるの！？ 実験せずに質問するますが、 EOFが抜けてたorz >>97 >>99 https://blog.emattsan.org/entry/20110819/1313743195 クラスFooの入力ストリーム演算子の中で整数を2個読むとして、 >>100 >>101 の状況ならフラグはもう立ってるから戻るだけで問題ないよ。 わかりた class A{ POD は削除された。 削除されたんですか？（バージョンいくつで？） >>109 >>104 POD が削除されたかどうかは重要ではなくて、 POD より弱い制約 (trivially copyable) で memcpy が許されるというのが主旨。 「構造体」ってのも C++ 用語的にはイケてないと思うよ。 アライメントは基本型のどれかと同じアライメント制約に合わせれば良いいということなら >>116 >>112 decltype(src.*p_)ってbase_なのでダメだろう ていうか、decltypeで型指定してるだけだからコピーもなにもされてないぞソレ A::base_に以下を足してA::derived_で実装し void*って、ポインターの先のサイズ未知だよなぁ derived_かそのメンバf_の型を知るにはRTTIしかないのですかね？ >>121 >>122 >>124 derived_(F f) ←この時点でムダなコピーが１度発生していることには気付いてる？ バッファの中にオブジェクトを作れたら、それで何をしたいのかが気になる >>127 たぶんやりたいことは std::allocator_traits::construct なのかな 例外って全部mainで捕捉すべきかな？ https://ideone.com/wSLZfL そもそもプログラムが終了してリソースリークするのかな？ >>133 OS管理なリソースはアプリの終了なんか知らないってのもあるからなぁ >>136 今どきのOS使ってたらOSリソースはリークしない そもそもアプリ的にデータの不整合とか出るから論外だろう よくあるのは異常終了時にファイルをフラッシュしておきたいとかだろ あとコアダンプの観点では例外飛ばさずに即死したほうがいい エラーだからって一時ファイル山盛り残して放置しないでください 質問した者だけど 例外処理って、メモリ破壊やファイルシステム破壊みたいな絶望的な状況を想定しなきゃいけないんだよ。 理想的には全ての例外はキャッチされるべき。 ただ、現実は理想的ではない。 じゃあ「投げられうるすべての例外に適切な対処ができるのが理想的だが、対処しきれない例外は投げられっぱなしにする（そしてプログラムを即座に異常終了させる）方が、思考停止でとりあえず捕捉しておくよりはまだマシ」ってことになるのかな いやいや、ちゃんとデバッグしろよ ライブラリ書くときはライブラリで対処できない例外は握り潰さずに上位で伝搬させろ！と言われてるよね 投げられっぱなしにするって言い方が不適切だったかな、別に例外のせいでプログラムが実際に異常終了するのを見ても知らんぷりするって意味じゃないよ 想定される状況には対処しているならどこで想定漏れがあるかはやってみないとわからない。 自分の知らないライブラリの奥底からいつ投げられるかわからない例外なんて対処しようがない やっぱC++の例外は悪…… やっぱ例外というﾌﾞﾂは、 >>154 >>149 )は つなみにOSの内部ではすべてのリソースをOSが管理する前提なので例外の出る幕は無い 何が返ってくるかわからん (ドキュメント化されていない) なら返却値の形になっていても正しく対処できないのは同じだろ。 例外だとテストしないドキュメントにも書かないというモラルハザードがおきやすいとは言えるだろう >>157 >>138 大きな目で全工程トータルを考えると全部の選択肢を適用する必要があるし、適用のしどころが違うと思うってのが>>136 の真意でした >>148 >>162 人命にかかわらない場合であっても、末端の関数が投げる例外の種類を見落としただけでプログラム全体が 何するか思い付かないならPG辞めろ >>167 んでテストケース爆増の話は？処理の具体例次第で話が変わったりするとか？ 依存関係のあるものに影響あるのは当たり前 それはいったい何のテストなんだろう。原因不明の例外を首尾よくキャッチできるかどうかテストしろと言っているんだろうか。 たとえば業務用のラベルプリンターでAPIが提供されてるとか すみません。質問させて下さい。次のコードがMinGW-w64 g++ v13.2では --itrでエラーになります。わからないのはVisual studio 2022およびVisual StudioがサポートするClang LLVMでは通って正しく >>177 https://timsong-cpp.github.io/cppwp/n3337/unord.set.overview#1 https://learn.microsoft.com/en-us/cpp/standard-library/unordered-set-class?view=msvc-170#iterator >>173 というわけでそんなの現実には不可能なので、現実的な処置としては catchしようがしまいが、例外が起きて 処理A→B→return となるのは同じだと思うが。 
