[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
262: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 6332-Kvqi) 2024/02/12(月)20:07 ID:4VueJhli0(2/2) AAS
Linux で * という名前のファイルを消そうとして
うわあぁぁぁとなった話はたまに聞く。
使えたとしても使うべきでない文字もある。
263: (ﾜｯﾁｮｲ f7cb-nOVH) 2024/02/12(月)21:44 ID:zGvIVge80(2/3) AAS
262>>
それ以外のファイルをすべて退避した上でディレクトリごと削除したことがあったな
264: (ﾜｯﾁｮｲ f7cb-nOVH) 2024/02/12(月)21:46 ID:zGvIVge80(3/3) AAS
すみません、261ですが、Windows限定の話ではなかったですね
失礼しました…
265: (ﾜｯﾁｮｲ 5edc-s3Gl) 2024/02/13(火)05:53 ID:QIUviIGO0(1) AAS
Linuxならi-nodeをしていすれば
findと組み合わせてどんな名前のファイルも消去できるんだけどなあ
windowsはなんか複雑だったような気がした
266(1): (ﾜｯﾁｮｲ 1e27-2ki6) 2024/02/13(火)09:36 ID:7CLA20rP0(1) AAS
iso8901にしない人はたぶんこの規格を知らないわけで意識低すぎだろと思ってしまう
267(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/13(火)11:18 ID:T85IlqBy0(1) AAS
>>266
ISO 8901 は情報交換用 (要するに機械同士のやり取り) の時刻フォーマットを定める規格であって
言葉や文章で使うもの (人間が読み書きする目的) ではないと適用範囲の言及がある。
ファイル名はどちらの用途もありうるので >>256 がどのような状況を想定しているかによって
ISO 8901 が適切かどうかは違う。
もし非技術者向けのシステムなら
文化固有の日付表現に対応できてないほうが意識低いという見方もある。
268: (ﾜｯﾁｮｲ 5ed7-nvep) 2024/02/13(火)12:55 ID:c63MYIIQ0(1) AAS
>>267
エンドユーザーの文化的背景に配慮したデータフォーマットの利点は、エンドユーザーの知識やメタファーを利用した学習曲線の低勾配化であって、技術的には負の遺産になりやすいことには注意が必要。
典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
あるいは大きな桁から始まるバイト列とか。あんなの１桁目から始めればエンディアン問題とか無かった。
269(1): (ﾜｯﾁｮｲ 12ad-v2JO) 2024/02/13(火)13:07 ID:mTl8FNrx0(1) AAS
> 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
それは人間から見たときと機械から見たときの見やすさの違いでしかないような気がする
でも日本の住所は大きい方から始まるんだよな
アメリカは個人から始まる
文化の違いやけども、日本人は機械生命体だったのかもしれぬ
270: (ﾜｯﾁｮｲ 6b74-e92p) 2024/02/15(木)04:22 ID:MOgQCM5N0(1) AAS
>>58
亀だがクロスで使ってるよ
271(1): (ﾜｯﾁｮｲ d62e-RfGy) 2024/02/16(金)22:41 ID:/bcZ41DF0(1) AAS
enable_shared_from_thisなクラスで、shared_from_this()はコンストラクタの中では
呼べないようですね
コンストラクタの中の処理でthisを渡したい処理があるのですが、どうしたら...
そもそもそれ自体が間違っているのでしょうか
コンストラクタが呼ばれる行の次でその処理を呼べばいいという説もありますが、
現在のコードがそれをやりにくい形になっていて
272(1): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/17(土)11:55 ID:hsYxYbKj0(1/2) AAS
>>250
>>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋
原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい
>>251
省8
273: (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/17(土)12:01 ID:hsYxYbKj0(2/2) AAS
>>253
藻前が二の句をつげないのは藻前の見識と資質の問題であって
漏れの責任ではないのでお間違えなきよう、
なのですよ……
274: (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)12:35 ID:mUyTgSzm0(1/4) AAS
テストって想定した動作環境、データ入力に対して想定した動作をするか確認をするわけで
想定しえないエラーや割り込みに対してはテストのしようがないんだけどな
そのための例外処理だろ
275: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)13:04 ID:4+T7+QKn0(1/3) AAS
例外が上がってくるってことはどこかで例外を投げてるってことだぞ。
問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。
想定してないなら例外送出すらできないよ。
その上で人間は大きいプログラムの全体を把握することは困難だし
機械的なチェックがしづらいという現実はあるって話だ。
276(1): (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)13:33 ID:mUyTgSzm0(2/4) AAS
アプリケーションを作っているのとOSを作っている人は別
それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか
アプリケーション開発者はそれらすべて想定できているとでも？
ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな
277: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)13:41 ID:4+T7+QKn0(2/3) AAS
>>276
「把握することは困難」という現実の話もしてる。
想定してはいて、しかしそれが伝わってない。
コミュニケーションの問題、自動化の問題として捉えるべき。
278(1): (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)13:56 ID:mUyTgSzm0(3/4) AAS
俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな
ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな
お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。
ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに ＊想定し＊ プログラムを組まなくてはならない
省5
279: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)15:09 ID:4+T7+QKn0(3/3) AAS
C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。 たとえ綺麗な方法ではなくても。
どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。
280(1): (ﾜｯﾁｮｲ e33b-hZ+C) 2024/02/17(土)15:39 ID:snTd9S980(1) AAS
>>271
一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので
コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか
そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか
281: (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)15:49 ID:mUyTgSzm0(4/4) AAS
> 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ
身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの
282(2): (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/17(土)20:37 ID:QSMcEn770(1/2) AAS
>>272
>原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい
相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ。
>return -1; は呼び出し側のバグで見落とすかもしれないが
>throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。
リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。
283(5): (ﾜｯﾁｮｲ 1e85-XyAm) 2024/02/17(土)23:18 ID:v62CV0mD0(1) AAS
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
省2
284(3): (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/17(土)23:48 ID:QSMcEn770(2/2) AAS
例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。
285(1): (ﾜｯﾁｮｲ 6fbc-ERL4) 2024/02/18(日)00:24 ID:JX7gxI3D0(1/2) AAS
>>284
例外の種類しか頭にないのか
任意の場所での例外発生に対応するなん現実的にできないということ
286: (ﾜｯﾁｮｲ ffe0-UH2C) 2024/02/18(日)09:00 ID:c1Urupub0(1) AAS
>>269
そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。
少なくとも例外みたいに変なフローで飛んで来ないし。
287(1): (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)09:39 ID:9f8IS57r0(1/3) AAS
ぶっちゃけ>>283がなに言ってるのかわからない
継続してそれが原因で？
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？
オブジェクトの状態が変わっているかも？
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
省2
288: (ﾜｯﾁｮｲ cfcf-sYtR) 2024/02/18(日)09:41 ID:WHoJTRhT0(1/2) AAS
>>285
>例外の種類しか頭にないのか
>>283が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
省1
289(1): (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)12:27 ID:9f8IS57r0(2/3) AAS
> これはどういう意味なんだろうな。
そうそれ
tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう
290: (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)12:28 ID:9f8IS57r0(3/3) AAS
もちょも は もっとも の まちがい
291(2): (ﾜｯﾁｮｲ 6f5b-ERL4) 2024/02/18(日)13:22 ID:JX7gxI3D0(2/2) AAS
>>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ
意味不明な例外が発生しました
データが破損してないかあなたが確認してください
動作無保証ですが処理継続しますか？yes/no
省1
292: (ﾜｯﾁｮｲ e304-hmqi) 2024/02/18(日)14:01 ID:6Yt/CDIt0(1) AAS
私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷
293: (ﾜｯﾁｮｲ ffad-mJpf) 2024/02/18(日)15:55 ID:1iQutSwY0(1) AAS
>>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある
294: (ﾜｯﾁｮｲ cfcf-sYtR) 2024/02/18(日)16:26 ID:WHoJTRhT0(2/2) AAS
>>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。
295: (ｽｯｯﾌﾟ Sd1f-p9fr) 2024/02/18(日)17:54 ID:L2mk1x1ad(1) AAS
>>289
もちょカワイイよね
296: (ﾜｯﾁｮｲ bf9a-/DPD) 2024/02/18(日)18:17 ID:LeQ06zof0(1) AAS
>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか
297: (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:41 ID:C77pR/Zl0(1/3) AAS
>>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか
で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……
298(1): (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:49 ID:C77pR/Zl0(2/3) AAS
>>284
例外安全というもののスコープに対して考察が足りていない
1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない
省4
299(2): (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:57 ID:C77pR/Zl0(3/3) AAS
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい
300(1): (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/03(日)21:57 ID:735dldsp0(1) AAS
>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。
301(1): (ﾜｯﾁｮｲ ef0a-qSkN) 2024/03/03(日)22:08 ID:qMaLplcd0(1) AAS
>>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの
302(1): (ﾜｯﾁｮｲ 3b7c-85wQ) 2024/03/03(日)22:31 ID:GdJ/jhkt0(1) AAS
>>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ
303: (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/04(月)00:08 ID:gWJ01aQ50(1/2) AAS
>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
悪魔の証明をテストすんのか
304: (ﾜｯﾁｮｲ ef0a-qSkN) 2024/03/04(月)07:57 ID:D3yk9beu0(1) AAS
>>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流
305: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)07:58 ID:KYG2Ugpe0(1/3) AAS
なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……
例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
省4
306: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)07:59 ID:KYG2Ugpe0(2/3) AAS
（※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる
307: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)08:09 ID:KYG2Ugpe0(3/3) AAS
あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
....
省6
308: (ﾜｯﾁｮｲ 9fad-ZLJX) 2024/03/04(月)08:50 ID:MzjtGtOW0(1) AAS
> なんか予想外に低ﾚなレスポンスを寄越した>>299……
299はお前自身じゃないのか、と俺は思う
309: (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/04(月)08:53 ID:gWJ01aQ50(2/2) AAS
>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。
310: (ﾜｯﾁｮｲ abe4-XE6S) 2024/03/04(月)10:20 ID:QvxlWFfk0(1/2) AAS
例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの
たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている）
311: (ﾜｯﾁｮｲ abe4-XE6S) 2024/03/04(月)10:23 ID:QvxlWFfk0(2/2) AAS
10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる
312: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 3b32-hL5K) 2024/03/04(月)12:10 ID:ASLjljy+0(1) AAS
誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。
313(1): (ﾜｯﾁｮｲ f7f0-B2uz) 2024/04/08(月)15:38 ID:IvxniXPw0(1) AAS
std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？
外部ﾘﾝｸ[html]:cpprefjp.github.io
314: (ﾜｯﾁｮｲ df01-g9Lk) 2024/04/09(火)12:13 ID:gepNgOiE0(1) AAS
どこのコピー?
315: (ﾌﾞｰｲﾓ MM3e-Nnmc) 2024/04/09(火)12:52 ID:80QuF/MqM(1) AAS
リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど
316(2): (ﾜｯﾁｮｲ 7b32-B3tP) 2024/04/09(火)15:22 ID:hsAXyuRl0(1) AAS
>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。
実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか？
というのはよく考えないといけない。
省2
317(2): (ﾜｯﾁｮｲ c3c9-hAMa) 2024/04/09(火)20:10 ID:T/amOWJO0(1) AAS
とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。
以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
省2
318: (ﾜｯﾁｮｲ f7f0-B2uz) 2024/04/09(火)20:30 ID:lDhzon+/0(1) AAS
>>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます
319: (ﾜｯﾁｮｲ 2790-Bmwq) 2024/04/09(火)21:45 ID:+RmfoJzl0(1) AAS
>>317
templateは型が違うと全くの別物として処理するからだと思う
320: (ﾜｯﾁｮｲ 7b10-qE2a) 2024/04/09(火)22:00 ID:5hAg3cgl0(1) AAS
>>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a)
321: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7b32-B3tP) 2024/04/10(水)08:39 ID:Fk7YBwaR0(1) AAS
const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。
322: (ﾜｯﾁｮｲ c37a-hAMa) 2024/04/11(木)21:42 ID:0cjrPM+u0(1) AAS
317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました
323(1): (ﾜｯﾁｮｲ b77c-0iQt) 2024/04/14(日)14:49 ID:tTNkn9kB0(1) AAS
先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？
324: (ﾜｯﾁｮｲ ff33-m4LK) 2024/04/14(日)15:03 ID:H7y3imqp0(1) AAS
あるよ。 外部ﾘﾝｸ:github.com
325: (ﾜｯﾁｮｲ 7f52-9wFU) 2024/04/16(火)00:50 ID:38VQ+8UT0(1) AAS
>>323
外部ﾘﾝｸ:www.reddit.com
326(1): (ﾜｯﾁｮｲ 67b1-Jq5A) 2024/05/01(水)21:36 ID:/DCu7vsT0(1) AAS
python みたいに何でも格納できる辞書型ってC++には無いよね？
327: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 8732-nVjz) 2024/05/01(水)22:29 ID:IV4TsWNk0(1) AAS
>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。
328: (ﾜｯﾁｮｲ 8f7c-Y/5H) 2024/05/09(木)20:23 ID:MzADiHDk0(1) AAS
外部ﾘﾝｸ[html]:cpprefjp.github.io
#elifって今まで非標準だったのかよ…
329: (ﾜｯﾁｮｲ bed6-w0ma) 2024/05/09(木)21:19 ID:M6C6+6vz0(1) AAS
何いってんだ
330: (ﾜｯﾁｮｲ bbda-JG92) 2024/05/10(金)11:53 ID:P+BretyD0(1) AAS
#elifは大昔からあるぞ
331: (ﾜｯﾁｮｲ 8f7c-Y/5H) 2024/05/11(土)09:12 ID:YR9R4Y390(1) AAS
cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？
332: (ﾜｯﾁｮｲ bed6-w0ma) 2024/05/11(土)11:19 ID:PrWZroBw0(1) AAS
規格が読めないならC++やめろ
333: (ﾜｯﾁｮｲ 0b63-IWIS) 2024/05/11(土)19:02 ID:RotYKdRC0(1) AAS
elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当
334: (ﾜｯﾁｮｲ bbda-JG92) 2024/05/11(土)22:20 ID:HBPowvO20(1) AAS
シェルが変だからな
case ～ esac
if ～ fi
335: 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)07:08 ID:Glzej5210(1/3) AAS
てｓｔ
336(1): 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)07:55 ID:Glzej5210(2/3) AAS
質問なのですが
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(1): (ﾌﾞｰｲﾓ MMde-FHn0) 2024/06/06(木)15:53 ID:Vp529NVwM(1) AAS
フル手書き前提がくそださい
338: (ﾜｯﾁｮｲ fe2c-7W3t) 2024/06/06(木)19:13 ID:FMMlTunO0(1) AAS
fstreamなんだったらfstreamのメンバで書くのがいいんじゃない
339: 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)23:36 ID:Glzej5210(3/3) AAS
(1)は#include <ios>が要るし、
(2)は「basic_」の6文字×フラグの数 だけ長いし、
(3)も同様でありなおかつ>>337に従ったとき
use binary = std::fstream::binary;
use ibinary = std::ifstream::binary;
use obinary = std::ofstream::binary;
となってしまい、
省3
340: (ﾜｯﾁｮｲ d68d-vvKF) 2024/06/06(木)23:54 ID:7ZzCG2hU0(1) AAS
iostreamはまあしゃーない…
341: (ﾜｯﾁｮｲ a97c-3xqL) 2024/06/07(金)02:20 ID:GhXFHGen0(1) AAS
C++の悪評の4割くらいはiostreamのせいだからな
342(2): (ﾜｯﾁｮｲ a944-l7CW) 2024/06/07(金)04:24 ID:qf+nnTv50(1) AAS
ここでCmakeとNinjaについて聞くのダメ?
どーも関係がよくわからなくて?
上下前次1-新書関写板覧索設栞歴
あと 660 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s