結局C++とRustってどっちが良いの？ 8traits

1 名前：デフォルトの名無しさん mailto:sage [2023/10/28(土) 13:45:00.38 ID:fh9BWjjr.net] 「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」 「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」 っていう雑談スレ。 ・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ ・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝 ・マな話は、マのスレもご活用ください↓ 前スレ: 結局C++とRustってどっちが良いの？ 7traits mevius.5ch.net/test/read.cgi/tech/1693451813/ 関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」 https://medaka.5ch.net/test/read.cgi/prog/1619943288/ 862 名前：デフォルトの名無しさん [2023/12/03(日) 23:06:04.65 ID:JMjzgwiz.net] ガジェットじゃなくて組み込みデバイスと言え 863 名前：デフォルトの名無しさん mailto:sage [2023/12/03(日) 23:16:00.90 ID:KItL/kTG.net] Rust使ってるとヒープ領域はスタック上のどこかの変数の運命共同体って感覚になるから ヒープだからコストが高いって言われると何か違和感がある Box（ヒープ配置）にするかしないかでたまに迷うけど 【スタック領域】 ・サイズが固定 ・確保、解放のオーバーヘッドがない ・スタック上で頻繁にコピーされるからでかいと不利 【ヒープ領域】 ・サイズが自由 ・確保、解放のオーバーヘッドがある ・基本的に移動しないからでかいときに有利 みたいなイメージで使い分けてる スタック／ヒープだから安全／危険とかは特にないな 864 名前：デフォルトの名無しさん [2023/12/03(日) 23:16:28.96 ID:hT/LokGW.net] 明日仕事がいやでストレスためてそうやなw 865 名前：デフォルトの名無しさん mailto:sage [2023/12/03(日) 23:38:17.10 ID:4Lj+S9P7.net] >>835 >>・スタック上で頻繁にコピーされるからでかいと不利 意図的に移動しない限りコピーはされない ヒープと同じで基本的に移動の必要はない 唯一コピーが起きそうに見える関数返しによる初期化はRVOによりコピーされない ヒープと同じで確保後はそこへの参照のみ扱うため移動コピーは起きない 866 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 00:12:41.83 ID:ista3uD6.net] Result型とかOk(T)とErr(E)のTとEが同じ場所に置かれそうだけどRVO機能するのかな 真面目に調べたことないけどあまり当てにしてない 最適化で適用されたらラッキーくらいの感覚 867 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 01:36:48.81 ID:DD5cHxD/.net] >>835 スタックは常にキャッシュにのってる 868 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 02:21:32.80 ID:7y9dHiQE.net] まあRustはこのまま死ぬんだからどうでもよくね？ 869 名前：デフォルトの名無しさん [2023/12/04(月) 03:52:22.51 ID:ukOfFF9P.net] >>840 おまえのレスよりは重要だろ？ 870 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 04:29:02.89 ID:IuiYb6LZ.net] >>840 お前自身がどうでもいい 871 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 05:55:52.64 ID:9MFLJqwq.net] >>833-834 ハンドヘルドとはいえ、64bitレジスタ当然、メモリもギガバイト当然、ってそんなの組み込みっていうんかｗ // てなことだと思う 872 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 10:07:12.79 ID:vGycO/bS.net] >>835 NGワードかもしれんが stackのメリットは基本的にGCのこと気にしなくて良くなる感覚 873 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 11:26:40.76 ID:t4TeK/vS.net] たまにバカでかいオブジェクトをスタックに置くやつが現れるが スタックは一度伸びたらするスレッド死ぬまで開放されないからメモリ無駄遣いになる 組み込みやコンソールゲーム作ってるとこだとスタックに置けるオブジェクトのサイズの制限決めてるとこあると思うけどチェックがムズいよな 昔仕事でライブラリ開発したときは最大スタック消費量が仕様で決まってた バグフィクスでもその上限超えてはならない 874 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 12:05:08.64 ID:EKSqu5ND.net] >>813 そりゃ、テンプレートとかは基本ライブラリアン向けの機能で、コーダーから複雑性を隠蔽ながら高度な機能を使わせるためのものだからな。 コーダーが自作テンプレートを使わなくてはならない状況になったら、何か設計が間違っていないか注意する必要がある。 まぁc++だとそういう状況もあるから辛いけど。 875 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 12:20:54.27 ID:EwsyjZMT.net] >>837 >意図的に移動しない限りコピーはされない これは微妙すぎる 「意図的」も「移動」も恣意的過ぎるから後出し無敵じゃんけんにしかならない コピーされないこともあるがコピーされる可能性を前提として最初から考えておくべき 876 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 12:32:02.91 ID:5v4NXSIj.net] Rustのmonomorphization使った静的ポリモーフィズムと同じようなことしたければC++はテンプレート必須だから ハイレベルのコードしか書かないアプリケーションプログラマーでも普通に使う必要があるでしょ 877 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 13:13:30.82 ID:TyudsW/I.net] >>845 そういやスタックは一度伸びたら伸びっぱなしだったな これ傍から見たらメモリリークにも見えるし 何でもスタックはあかんのじゃないか 878 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 13:29:26.93 ID:+6ZMbPCa.net] 誰からも指摘されずにどんどん明後日の方向に向かって行っているのは見てる分には面白い どうか第2の毛の壁と化しませんように 南無阿弥陀仏 879 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 13:38:09.73 ID:EKSqu5ND.net] >>849 スタックの取扱いを調整すればよろし。 コールスタックとデータスタックを分けてデータスタックをメモリブロックにするとか、大きいのはマネージドヒープに置くようにするとか。 だんだんヒープに近くなるからスタックのメリットは無くなるけど。 880 名前：デフォルトの名無しさん [2023/12/04(月) 19:31:46.91 ID:Vux7QnQs.net] コードをよりコンパクトな短文にしようと追求したらテンプレートを使うようになるのはごく当たり前だよ 881 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 19:42:38.90 ID:BRBvRtzF.net] >>835 モダンなC++もそれだぞ class Hoge { private: std::shared_ptr<HogeInternal> hoge; }; Hogeは常にスタックに割り当てる 実際のオブジェクトはHogeInternalで実装する こうしておけばめちゃくちゃ安全になる 882 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 19:56:42.31 ID:S3L8tG/0.net] なんで馬鹿はshared_ptr使いたがるんだろう 生ポでいいだろ 883 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 20:13:20.11 ID:ista3uD6.net] 3/5/0則を知らないもっと馬鹿なやつがdelete用のデストラクタだけ実装して 事故が多 884 名前：発したからでは [] [ここ壊れてます] 885 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 20:18:13.44 ID:61k0lpUm.net] >>853 それはHogeInternalがヒープ領域に置かれてしまいスタック領域の利用ではない さらに参照カウントのオーバーヘッドもある 886 名前：デフォルトの名無しさん [2023/12/04(月) 20:23:01.45 ID:lyR6TlPF.net] C++、雰囲気で書いたらすぐに壊れるくせに文法がどんどん増えていくのついていけねえわ どんだけの勉強コストを一つの言語に払わせる気だよ C++に人生捧げて他のこと何も出来ない無能だけが扱える言語となりつつある 887 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 20:27:01.58 ID:648vwdUw.net] 3/5/0則みたいな言語の欠陥に疑問を持たなくなったらもう終わり 888 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 20:31:26.59 ID:KZyfgQnR.net] >>856 いだから置くんだよ 伝わってないみたいだから説明するとHogeに直接実装しないってことを言ってる 間接参照を一段挟むのよ こうすることでコピーしまくっても問題ないヒープに確保されたオブジェクトができる 多少オーバーヘッドは生まれるがめちゃくちゃ安全性は上がるんよ 889 名前：デフォルトの名無しさん [2023/12/04(月) 20:32:20.03 ID:oiJ5wZfJ.net] そそ、難解な概念使いこなせるのはすごいけど、会社でマウントとれるだけ 世の中が求めてるのはそこじゃない。 890 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 20:59:36.17 ID:H6ggqIOp.net] >>859 Rustを使えばヒープではなくスタック領域に確保してそこへの参照をオーバーヘッドなしで安全に使えるよ その点がRustとC++の差 891 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:10:50.41 ID:61k0lpUm.net] >>859 ヒープを使うというオーバーヘッドに加えて 参照カウントを使うというオーバーヘッドまで加わる もちろん各々が不可欠な場合や両方が不可欠な場合もあるがその前提や吟味をせずに まともなプログラマーがとる選択肢ではない 892 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:14:53.25 ID:KZyfgQnR.net] >>862 嫌だから共有が必要な場合って書いてあるだろ 日本語読める？ 共有じゃないならstd::unique_ptrでもいいよ 893 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:15:11.88 ID:KZyfgQnR.net] Hogeに実装しないことでコピー時のオーバーヘッドを防ぐ さらに個別にコピーのことを考える必要性がなくなる HogeInternalのコピーコストだけで済むため高速 shared_ptrは安全にコピー可能 データは共有できメモリ管理も自動で行われる ヒープにとらなきゃいけなくて共有する可能性があるオブジェクトはこのパターンで実装してください マジで何も考えなくていいから 894 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:18:26.98 ID:KZyfgQnR.net] >>861 C++で極力Rustっぽく書くにはどうすべきかを突き詰めたらこうなった 褒めてくれ 895 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:25:29.71 ID:H6ggqIOp.net] >>863 Rustなら参照の共有はヒープを使わずスタックに置いてあるものに対しても安全に可能です もちろん参照カウンタは必要ありません ちなみにRustでC++のshared_ptrに相当するRc/Arcを必要とするのはもっと限定された状況で所有の共有が必要となる時のみです 896 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:32:42.16 ID:KZyfgQnR.net] 新たな間接参照でラップすることであたかも普通の変数を作るかのようにヒープに値を置ける このパターンめちゃくちゃ有用なんだがなぜあらゆる本で紹介されてないんだ？ 897 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:35:03.72 ID:KZyfgQnR.net] コロンブスの卵だわ 誰もが思いつきそうで思いつかなかった 898 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:39:30.12 ID:KZyfgQnR.net] >>866 まあその辺はさすがRust 899 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 21:41:03.87 ID:ista3uD6.net] 本気でRustに寄せるならunique_ptrの方がいいな コンパイラが助けてくれないから死にそうだけど とりあえず循環参照だけは気を付けてくれ >>867 目的はちょっと違うけどPimplってイディオムがある 900 名前：デフォルトの名無しさん [2023/12/04(月) 21:54:58.33 ID:85Eugi9n.net] 継承じゃ無くて、包含して各メソッドをバトン渡しすれば良くね？ 901 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 22:45:48.75 ID:t1H4jiv7.net] >>867 他のやつも書いてるけどpimplな 20年前から知られている ひたすらdelegate関数を書くのがだるい 使う側がshared_ptrで包むというルールのほうが楽 902 名前：デフォルトの名無しさん [2023/12/04(月) 23:15:56.57 ID:o6jCQk0t.net] >>872 >ひたすらdelegate関数を書くのがだるい 書かねば良いのでは? 903 名前：デフォルトの名無しさん mailto:sage [2023/12/04(月) 23:53:40.38 ID:xybHpH7g.net] >>867 間接参照でいいならわざわざクラスでラップしなくてもshared_ptrそのものでいいように思うんだが shared_ptr<HogeInternal>で扱うより ラップしたHogeで扱ったほうがいいメリットって何？ 904 名前：デフォルトの名無しさん [2023/12/05(火) 00:09:25.25 ID:NEqb8LdH.net] mallocでメモリ確保するの気持ちイィ🥴 905 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 00:55:04.31 ID:gtr9NjJz.net] >>872 20年前にこの概念が存在していたのか 当時はauto_ptrとかオレオレメモリ管理モジュールだったとは思うけど 906 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 00:58:42.15 ID:gtr9NjJz.net] >>872 ライブラリとして定期したい場合はshared_ptrで常に包むルールを強制するのも難しいとかかな 907 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 04:45:21.81 ID:55rynLOP.net] delegate指定子欲しいよな。 クラスor変数でまとめて指定できればなお良し。 908 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 05:43:53.62 ID:DR8rm2oC.net] それってRustのDeref？ 909 名前：デフォルトの名無しさん [2023/12/05(火) 08:01:23.94 ID:HiCWBikd.net] std::byteを使ってみた結果 危険な計算ができるのがC/C++を使う理由という結論になった 910 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 08:50:09.72 ID:iiJ5Z2H1.net] 一人で何役やってるの？ 911 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 09:49:41.30 ID:Akhn3hwz.net] >>881 数えてみろよ 912 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 10:22:23.63 ID:0dgzhl7w.net] >>877 Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは？ 913 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 10:50:40.33 ID:cS2yZHjP.net] >>879 delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。 参照外しとかして型を変えるのはNG。 914 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 11:56:35.63 ID:pNurA5HJ.net] Rustのdelegate!のようなことがC++ではまだ出来ないということか 汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな 915 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 13:26:22.00 ID:iiJ5Z2H1.net] >>882 こういうキチガイ対策にワッチョイ必要かもな 916 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 13:34:36.87 ID:gtr9NjJz.net] >>882 きっしょw 917 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 14:18:15.60 ID:DR8rm2oC.net] >>884 スマートポインタなのだから Derefにより自動的に参照できれば十分だろ 918 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 14:23:46.88 ID:4UYj/sQ8.net] ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ 919 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 14:24:46.44 ID:4UYj/sQ8.net] ×立てたってところで ○立てたところで 920 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 14:31:18.82 ID:1iJo44eg.net] Adaptorにだけ執拗にこだわるオジもアレだか Adaptorも知らずにDerefを勧めるオジは論外 921 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 14:58:30.60 ID:gtr9NjJz.net] >>883 ユーザーに返す型では流石に気持ち悪いと思うなあ C++難し過ぎるだろ 選択肢が多過ぎる かといって安全でもない もうRust使わせてくれ 922 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 15:21:39.57 ID:MywljXTh.net] >>892 別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない (生ポインタはありえない) だからそこを気持ち悪いと言っても仕方ない 923 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 15:51:48.29 ID:Nvodex4n.net] >>892 Rustでもそこは同じだと思うよ ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある � 924 名前：Vンプルなケースなら前者の方が圧倒的に使いやすい 内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ 要はラップするだけの付加価値があるかどうか [] [ここ壊れてます] 925 名前：デフォルトの名無しさん [2023/12/05(火) 15:52:25.13 ID:QJai9ytv.net] >>854 馬鹿は平気で二重に解放したりする 全然気にしないから馬鹿なんだけどね 926 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 16:00:15.02 ID:8v2tQb+c.net] >>854 いやいやいやいやw 927 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 16:26:52.90 ID:sq6EbAl6.net] リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない？ 928 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 16:45:36.42 ID:iiJ5Z2H1.net] >>889 えー 929 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 16:47:29.78 ID:MywljXTh.net] ならない リアルタイム系アプリでGCは困る 930 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 17:17:38.64 ID:CoP1YuvK.net] 循環参照で発生するリークを検出するか放置するか あるいは循環参照を回避するか それが問題だ 931 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 17:29:27.24 ID:W0r7TCUZ.net] >>899 マークスウィープの話をしてないぞ リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる 932 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 17:59:20.81 ID:ugZXhcp8.net] 手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない 手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる そのため複数所有者を使わざるを得ない場合に限定して用いる 933 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 18:13:07.15 ID:Ppu4uIXE.net] >>902 Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ 934 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 18:43:14.63 ID:gtr9NjJz.net] >>894 気持ち的にはラップしたいかなあ 935 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 19:04:48.69 ID:gtr9NjJz.net] 全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/ Rustを使えばいいじゃない 936 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 19:13:25.15 ID:gquaqYbt.net] IBMだったらJavaだったのに 937 名前：デフォルトの名無しさん [2023/12/05(火) 19:18:25.05 ID:800y2Su3.net] 積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ 938 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 19:24:31.25 ID:GrTJwyK/.net] Cとの互換性 939 名前：デフォルトの名無しさん [2023/12/05(火) 19:32:43.32 ID:4rw/VL0P.net] >>897 問題はGC言語は *常に* GC機能ありなところ。 940 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 19:40:36.09 ID:iiJ5Z2H1.net] >>907 オブジェクト指向ｗ 941 名前：デフォルトの名無しさん [2023/12/05(火) 20:04:51.38 ID:3vhS3QGH.net] リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな mallocはプログラムの最初に一回呼ぶ以外は許されない 942 名前：デフォルトの名無しさん [2023/12/05(火) 20:31:30.51 ID:GM9Glwep.net] >>907 組み込み系でオブジェクトやりたい人 あと意図的に悪意あるコードを仕込む人とか。 943 名前：デフォルトの名無しさん [2023/12/05(火) 21:15:38.20 ID:HiCWBikd.net] やりたいことが出来るのが一番の理由 アンリミテッドが魅力 944 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 21:36:14.43 ID:9fH1d+k3.net] 参照カウントて結構コストあったよな……と探したら解説見つけた。 yamasa.hatenablog.jp/entry/2021/01/29/012525 昔は並列処理と相性悪いと言われていたけど、今はどうかね？ 945 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 21:36:19.50 ID:ckmQfDX3.net] ++C Unsafety Unlimited C++ 946 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 21:43:08.45 ID:tZxAn7Rl.net] >>909 GC言語でもunsafeで手動 947 名前：管理とかできるよ Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ [] [ここ壊れてます] 948 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 21:59:57.96 ID:puqODfvy.net] >>902 >そのため複数所有者を使わざるを得ない場合に限定して用いる 複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全 C++は逆もある >>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは 949 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 22:10:46.45 ID:vNAfxFS3.net] >>911 RAII自体はコストゼロ RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる そしてヒープ領域を所有していればヒープ解放コストがかかる 何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい スタック領域で済ませられるならさらに望ましい 950 名前：デフォルトの名無しさん mailto:sage [2023/12/05(火) 22:57:00.41 ID:iiJ5Z2H1.net] 全部独り言だったりしてｗ 951 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 01:20:30.01 ID:N0N71GtG.net] メモリに展開するのにオーバーフローしてもエラーを通知しないの？ https://japan.zdnet.com/article/35212258/ 言語はCらしいけどどういうプログラムなんだろう まじでmallocしてそこにmemcpyしてるだけなんじゃないか 対策はRustで書き直せ 952 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 01:23:15.09 ID:N0N71GtG.net] たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう どうせオフセットも手計算だろうし 953 名前：デフォルトの名無しさん [2023/12/06(水) 01:40:45.31 ID:MT5mgeUa.net] >>916 ＞>>909 ＞GC言語でもunsafeで手動管理とかできるよ どの言語？具体名あげてくれ。 954 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 01:58:21.86 ID:+XLnMsko.net] [gc unsafe] [🔍] 955 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 09:15:07.04 ID:oM0gjrfW.net] >>867-868 循環参照は？ 956 名前：デフォルトの名無しさん [2023/12/06(水) 09:17:14.31 ID:oM0gjrfW.net] >>867 >あらゆる本で紹介されてない a)全ての本で紹介されていない b)紹介された本がひとつもない どっちの意味？念のため確認 957 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 09:18:07.12 ID:oM0gjrfW.net] >925 補足 a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある) 958 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 09:20:39.56 ID:oM0gjrfW.net] >>868 思い付いている人は大勢居る >>865 >C++で極力Rustっぽく書く いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ きみ承認欲求強過ぎるね 959 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 10:53:51.94 ID:CNnXy5JV.net] >>922 メジャーなとこで言えばC#とかSwiftとか 960 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 11:45:54.12 ID:oM0gjrfW.net] >>905 やっぱりNATテーブル不良で再起動したら治るルーターじゃん 961 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 12:09:32.50 ID:4VSkBLs6.net] >>929 頭大丈夫か？ 962 名前：デフォルトの名無しさん mailto:sage [2023/12/06(水) 12:31:44.18 ID:3kI3ay52.net] 型推論の是非を問いたい 書くのは楽かもしれないが読みにくくね？ 型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる 読みやすさを優先すべきだと思うがどうだろう IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな

---

---

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

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