[過去ﾛｸﾞ] 結局C++とRustってどっちが良いの？ 8traits (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
831: 2023/12/03(日)22:55 ID:idvLkFW9(1)調 AAS
RVOにより呼び出し元でスタック領域を確保できつつ
Rustのようにスタック領域に対しても自動的にライフタイム管理ができていれば
コストの高いヒープ領域利用を可能な限り減らしつつ
スタック領域を指す参照(ポインタ)を返したり他へ埋め込んだりしていても安全に使える
というシンプルな話
832: 2023/12/03(日)23:01 ID:hT/LokGW(1/2)調 AAS
C++もRustもベアメタルという土俵で真価を問われると思うよ
小型軽量ガジェットでAIを高速に処理出る言語に需要があると思ってる。
833(1): 2023/12/03(日)23:04 ID:8f6BMxsw(1)調 AAS
ねーわw
ガジェットww
834(1): 2023/12/03(日)23:06 ID:JMjzgwiz(1)調 AAS
ガジェットじゃなくて組み込みデバイスと言え
835(4): 2023/12/03(日)23:16 ID:KItL/kTG(2/2)調 AAS
Rust使ってるとヒープ領域はスタック上のどこかの変数の運命共同体って感覚になるから
ヒープだからコストが高いって言われると何か違和感がある
Box（ヒープ配置）にするかしないかでたまに迷うけど
【スタック領域】
・サイズが固定
・確保、解放のオーバーヘッドがない
・スタック上で頻繁にコピーされるからでかいと不利
【ヒープ領域】
・サイズが自由
・確保、解放のオーバーヘッドがある
・基本的に移動しないからでかいときに有利
みたいなイメージで使い分けてる
スタック／ヒープだから安全／危険とかは特にないな
836: 2023/12/03(日)23:16 ID:hT/LokGW(2/2)調 AAS
明日仕事がいやでストレスためてそうやなw
837(1): 2023/12/03(日)23:38 ID:4Lj+S9P7(1)調 AAS
>>835
>>・スタック上で頻繁にコピーされるからでかいと不利
意図的に移動しない限りコピーはされない
ヒープと同じで基本的に移動の必要はない
唯一コピーが起きそうに見える関数返しによる初期化はRVOによりコピーされない
ヒープと同じで確保後はそこへの参照のみ扱うため移動コピーは起きない
838: 2023/12/04(月)00:12 ID:ista3uD6(1/3)調 AAS
Result型とかOk(T)とErr(E)のTとEが同じ場所に置かれそうだけどRVO機能するのかな
真面目に調べたことないけどあまり当てにしてない
最適化で適用されたらラッキーくらいの感覚
839: 2023/12/04(月)01:36 ID:DD5cHxD/(1)調 AAS
>>835
スタックは常にキャッシュにのってる
840(2): 2023/12/04(月)02:21 ID:7y9dHiQE(1)調 AAS
まあRustはこのまま死ぬんだからどうでもよくね？
841: 2023/12/04(月)03:52 ID:ukOfFF9P(1)調 AAS
>>840
おまえのレスよりは重要だろ？
842: 2023/12/04(月)04:29 ID:IuiYb6LZ(1)調 AAS
>>840
お前自身がどうでもいい
843: 2023/12/04(月)05:55 ID:9MFLJqwq(1)調 AAS
>>833-834
ハンドヘルドとはいえ、64bitレジスタ当然、メモリもギガバイト当然、ってそんなの組み込みっていうんかｗ
// てなことだと思う
844: 2023/12/04(月)10:07 ID:vGycO/bS(1)調 AAS
>>835
NGワードかもしれんが
stackのメリットは基本的にGCのこと気にしなくて良くなる感覚
845(1): 2023/12/04(月)11:26 ID:t4TeK/vS(1)調 AAS
たまにバカでかいオブジェクトをスタックに置くやつが現れるが
スタックは一度伸びたらするスレッド死ぬまで開放されないからメモリ無駄遣いになる
組み込みやコンソールゲーム作ってるとこだとスタックに置けるオブジェクトのサイズの制限決めてるとこあると思うけどチェックがムズいよな
昔仕事でライブラリ開発したときは最大スタック消費量が仕様で決まってた
バグフィクスでもその上限超えてはならない
846: 2023/12/04(月)12:05 ID:EKSqu5ND(1/2)調 AAS
>>813
そりゃ、テンプレートとかは基本ライブラリアン向けの機能で、コーダーから複雑性を隠蔽ながら高度な機能を使わせるためのものだからな。
コーダーが自作テンプレートを使わなくてはならない状況になったら、何か設計が間違っていないか注意する必要がある。
まぁc++だとそういう状況もあるから辛いけど。
847: 2023/12/04(月)12:20 ID:EwsyjZMT(1)調 AAS
>>837
>意図的に移動しない限りコピーはされない
これは微妙すぎる
「意図的」も「移動」も恣意的過ぎるから後出し無敵じゃんけんにしかならない
コピーされないこともあるがコピーされる可能性を前提として最初から考えておくべき
848: 2023/12/04(月)12:32 ID:5v4NXSIj(1)調 AAS
Rustのmonomorphization使った静的ポリモーフィズムと同じようなことしたければC++はテンプレート必須だから
ハイレベルのコードしか書かないアプリケーションプログラマーでも普通に使う必要があるでしょ
849(1): 2023/12/04(月)13:13 ID:TyudsW/I(1)調 AAS
>>845
そういやスタックは一度伸びたら伸びっぱなしだったな
これ傍から見たらメモリリークにも見えるし
何でもスタックはあかんのじゃないか
850: 2023/12/04(月)13:29 ID:+6ZMbPCa(1)調 AAS
誰からも指摘されずにどんどん明後日の方向に向かって行っているのは見てる分には面白い
どうか第2の毛の壁と化しませんように
南無阿弥陀仏
851: 2023/12/04(月)13:38 ID:EKSqu5ND(2/2)調 AAS
>>849
スタックの取扱いを調整すればよろし。
コールスタックとデータスタックを分けてデータスタックをメモリブロックにするとか、大きいのはマネージドヒープに置くようにするとか。
だんだんヒープに近くなるからスタックのメリットは無くなるけど。
852: 2023/12/04(月)19:31 ID:Vux7QnQs(1)調 AAS
コードをよりコンパクトな短文にしようと追求したらテンプレートを使うようになるのはごく当たり前だよ
853(2): 2023/12/04(月)19:42 ID:BRBvRtzF(1)調 AAS
>>835
モダンなC++もそれだぞ
class Hoge {
private:
std::shared_ptr<HogeInternal> hoge;
};
Hogeは常にスタックに割り当てる
実際のオブジェクトはHogeInternalで実装する
こうしておけばめちゃくちゃ安全になる
854(2): 2023/12/04(月)19:56 ID:S3L8tG/0(1)調 AAS
なんで馬鹿はshared_ptr使いたがるんだろう
生ポでいいだろ
855: 2023/12/04(月)20:13 ID:ista3uD6(2/3)調 AAS
3/5/0則を知らないもっと馬鹿なやつがdelete用のデストラクタだけ実装して
事故が多発したからでは
856(1): 2023/12/04(月)20:18 ID:61k0lpUm(1/2)調 AAS
>>853
それはHogeInternalがヒープ領域に置かれてしまいスタック領域の利用ではない
さらに参照カウントのオーバーヘッドもある
857: 2023/12/04(月)20:23 ID:lyR6TlPF(1)調 AAS
C++、雰囲気で書いたらすぐに壊れるくせに文法がどんどん増えていくのついていけねえわ
どんだけの勉強コストを一つの言語に払わせる気だよ
C++に人生捧げて他のこと何も出来ない無能だけが扱える言語となりつつある
858: 2023/12/04(月)20:27 ID:648vwdUw(1)調 AAS
3/5/0則みたいな言語の欠陥に疑問を持たなくなったらもう終わり
859(2): 2023/12/04(月)20:31 ID:KZyfgQnR(1/7)調 AAS
>>856
いだから置くんだよ
伝わってないみたいだから説明するとHogeに直接実装しないってことを言ってる
間接参照を一段挟むのよ
こうすることでコピーしまくっても問題ないヒープに確保されたオブジェクトができる
多少オーバーヘッドは生まれるがめちゃくちゃ安全性は上がるんよ
860: 2023/12/04(月)20:32 ID:oiJ5wZfJ(1)調 AAS
そそ、難解な概念使いこなせるのはすごいけど、会社でマウントとれるだけ
世の中が求めてるのはそこじゃない。
861(1): 2023/12/04(月)20:59 ID:H6ggqIOp(1/2)調 AAS
>>859
Rustを使えばヒープではなくスタック領域に確保してそこへの参照をオーバーヘッドなしで安全に使えるよ
その点がRustとC++の差
862(1): 2023/12/04(月)21:10 ID:61k0lpUm(2/2)調 AAS
>>859
ヒープを使うというオーバーヘッドに加えて
参照カウントを使うというオーバーヘッドまで加わる
もちろん各々が不可欠な場合や両方が不可欠な場合もあるがその前提や吟味をせずに
まともなプログラマーがとる選択肢ではない
863(1): 2023/12/04(月)21:14 ID:KZyfgQnR(2/7)調 AAS
>>862
嫌だから共有が必要な場合って書いてあるだろ
日本語読める？
共有じゃないならstd::unique_ptrでもいいよ
864: 2023/12/04(月)21:15 ID:KZyfgQnR(3/7)調 AAS
Hogeに実装しないことでコピー時のオーバーヘッドを防ぐ
さらに個別にコピーのことを考える必要性がなくなる
HogeInternalのコピーコストだけで済むため高速
shared_ptrは安全にコピー可能
データは共有できメモリ管理も自動で行われる
ヒープにとらなきゃいけなくて共有する可能性があるオブジェクトはこのパターンで実装してください
マジで何も考えなくていいから
865(1): 2023/12/04(月)21:18 ID:KZyfgQnR(4/7)調 AAS
>>861
C++で極力Rustっぽく書くにはどうすべきかを突き詰めたらこうなった
褒めてくれ
866(1): 2023/12/04(月)21:25 ID:H6ggqIOp(2/2)調 AAS
>>863
Rustなら参照の共有はヒープを使わずスタックに置いてあるものに対しても安全に可能です
もちろん参照カウンタは必要ありません
ちなみにRustでC++のshared_ptrに相当するRc/Arcを必要とするのはもっと限定された状況で所有の共有が必要となる時のみです
867(5): 2023/12/04(月)21:32 ID:KZyfgQnR(5/7)調 AAS
新たな間接参照でラップすることであたかも普通の変数を作るかのようにヒープに値を置ける
このパターンめちゃくちゃ有用なんだがなぜあらゆる本で紹介されてないんだ？
868(2): 2023/12/04(月)21:35 ID:KZyfgQnR(6/7)調 AAS
コロンブスの卵だわ
誰もが思いつきそうで思いつかなかった
869: 2023/12/04(月)21:39 ID:KZyfgQnR(7/7)調 AAS
>>866
まあその辺はさすがRust
870: 2023/12/04(月)21:41 ID:ista3uD6(3/3)調 AAS
本気でRustに寄せるならunique_ptrの方がいいな
コンパイラが助けてくれないから死にそうだけど
とりあえず循環参照だけは気を付けてくれ
>>867
目的はちょっと違うけどPimplってイディオムがある
871: 2023/12/04(月)21:54 ID:85Eugi9n(1)調 AAS
継承じゃ無くて、包含して各メソッドをバトン渡しすれば良くね？
872(3): 2023/12/04(月)22:45 ID:t1H4jiv7(1)調 AAS
>>867
他のやつも書いてるけどpimplな
20年前から知られている
ひたすらdelegate関数を書くのがだるい
使う側がshared_ptrで包むというルールのほうが楽
873: 2023/12/04(月)23:15 ID:o6jCQk0t(1)調 AAS
>>872
>ひたすらdelegate関数を書くのがだるい
書かねば良いのでは?
874: 2023/12/04(月)23:53 ID:xybHpH7g(1)調 AAS
>>867
間接参照でいいならわざわざクラスでラップしなくてもshared_ptrそのものでいいように思うんだが
shared_ptr<HogeInternal>で扱うより
ラップしたHogeで扱ったほうがいいメリットって何？
875: 2023/12/05(火)00:09 ID:NEqb8LdH(1)調 AAS
mallocでメモリ確保するの気持ちイィ🥴
876: 2023/12/05(火)00:55 ID:gtr9NjJz(1/6)調 AAS
>>872
20年前にこの概念が存在していたのか
当時はauto_ptrとかオレオレメモリ管理モジュールだったとは思うけど
877(1): 2023/12/05(火)00:58 ID:gtr9NjJz(2/6)調 AAS
>>872
ライブラリとして定期したい場合はshared_ptrで常に包むルールを強制するのも難しいとかかな
878: 2023/12/05(火)04:45 ID:55rynLOP(1)調 AAS
delegate指定子欲しいよな。
クラスor変数でまとめて指定できればなお良し。
879(1): 2023/12/05(火)05:43 ID:DR8rm2oC(1/2)調 AAS
それってRustのDeref？
880: 2023/12/05(火)08:01 ID:HiCWBikd(1/2)調 AAS
std::byteを使ってみた結果
危険な計算ができるのがC/C++を使う理由という結論になった
881(1): 2023/12/05(火)08:50 ID:iiJ5Z2H1(1/5)調 AAS
一人で何役やってるの？
882(2): 2023/12/05(火)09:49 ID:Akhn3hwz(1)調 AAS
>>881
数えてみろよ
883(1): 2023/12/05(火)10:22 ID:0dgzhl7w(1)調 AAS
>>877
Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは？
884(1): 2023/12/05(火)10:50 ID:cS2yZHjP(1)調 AAS
>>879
delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。
参照外しとかして型を変えるのはNG。
885: 2023/12/05(火)11:56 ID:pNurA5HJ(1)調 AAS
Rustのdelegate!のようなことがC++ではまだ出来ないということか
汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな
886: 2023/12/05(火)13:26 ID:iiJ5Z2H1(2/5)調 AAS
>>882
こういうキチガイ対策にワッチョイ必要かもな
887: 2023/12/05(火)13:34 ID:gtr9NjJz(3/6)調 AAS
>>882
きっしょw
888: 2023/12/05(火)14:18 ID:DR8rm2oC(2/2)調 AAS
>>884
スマートポインタなのだから
Derefにより自動的に参照できれば十分だろ
889(1): 2023/12/05(火)14:23 ID:4UYj/sQ8(1/2)調 AAS
ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ
890: 2023/12/05(火)14:24 ID:4UYj/sQ8(2/2)調 AAS
×立てたってところで
○立てたところで
891: 2023/12/05(火)14:31 ID:1iJo44eg(1)調 AAS
Adaptorにだけ執拗にこだわるオジもアレだか
Adaptorも知らずにDerefを勧めるオジは論外
892(2): 2023/12/05(火)14:58 ID:gtr9NjJz(4/6)調 AAS
>>883
ユーザーに返す型では流石に気持ち悪いと思うなあ
C++難し過ぎるだろ
選択肢が多過ぎる
かといって安全でもない
もうRust使わせてくれ
893: 2023/12/05(火)15:21 ID:MywljXTh(1/2)調 AAS
>>892
別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない
(生ポインタはありえない)
だからそこを気持ち悪いと言っても仕方ない
894(1): 2023/12/05(火)15:51 ID:Nvodex4n(1)調 AAS
>>892
Rustでもそこは同じだと思うよ
ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある
シンプルなケースなら前者の方が圧倒的に使いやすい
内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ
要はラップするだけの付加価値があるかどうか
895: 2023/12/05(火)15:52 ID:QJai9ytv(1)調 AAS
>>854
馬鹿は平気で二重に解放したりする
全然気にしないから馬鹿なんだけどね
896: 2023/12/05(火)16:00 ID:8v2tQb+c(1)調 AAS
>>854
いやいやいやいやw
897(1): 2023/12/05(火)16:26 ID:sq6EbAl6(1)調 AAS
リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない？
898: 2023/12/05(火)16:45 ID:iiJ5Z2H1(3/5)調 AAS
>>889
えー
899(1): 2023/12/05(火)16:47 ID:MywljXTh(2/2)調 AAS
ならない
リアルタイム系アプリでGCは困る
900: 2023/12/05(火)17:17 ID:CoP1YuvK(1)調 AAS
循環参照で発生するリークを検出するか放置するか
あるいは循環参照を回避するか
それが問題だ
901: 2023/12/05(火)17:29 ID:W0r7TCUZ(1)調 AAS
>>899
マークスウィープの話をしてないぞ
リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる
902(2): 2023/12/05(火)17:59 ID:ugZXhcp8(1)調 AAS
手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない
手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト
その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる
そのため複数所有者を使わざるを得ない場合に限定して用いる
903: 2023/12/05(火)18:13 ID:Ppu4uIXE(1)調 AAS
>>902
Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ
904: 2023/12/05(火)18:43 ID:gtr9NjJz(5/6)調 AAS
>>894
気持ち的にはラップしたいかなあ
905(1): 2023/12/05(火)19:04 ID:gtr9NjJz(6/6)調 AAS
全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/
Rustを使えばいいじゃない
906: 2023/12/05(火)19:13 ID:gquaqYbt(1)調 AAS
IBMだったらJavaだったのに
907(2): 2023/12/05(火)19:18 ID:800y2Su3(1)調 AAS
積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ
908: 2023/12/05(火)19:24 ID:GrTJwyK/(1)調 AAS
Cとの互換性
909(2): 2023/12/05(火)19:32 ID:4rw/VL0P(1)調 AAS
>>897
問題はGC言語は *常に* GC機能ありなところ。
910: 2023/12/05(火)19:40 ID:iiJ5Z2H1(4/5)調 AAS
>>907
オブジェクト指向ｗ
911(1): 2023/12/05(火)20:04 ID:3vhS3QGH(1)調 AAS
リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな
mallocはプログラムの最初に一回呼ぶ以外は許されない
912: 2023/12/05(火)20:31 ID:GM9Glwep(1)調 AAS
>>907
組み込み系でオブジェクトやりたい人
あと意図的に悪意あるコードを仕込む人とか。
913: 2023/12/05(火)21:15 ID:HiCWBikd(2/2)調 AAS
やりたいことが出来るのが一番の理由
アンリミテッドが魅力
914: 2023/12/05(火)21:36 ID:9fH1d+k3(1)調 AAS
参照カウントて結構コストあったよな……と探したら解説見つけた。
yamasa.hatenablog.jp/entry/2021/01/29/012525
昔は並列処理と相性悪いと言われていたけど、今はどうかね？
915: 2023/12/05(火)21:36 ID:ckmQfDX3(1)調 AAS
++C Unsafety Unlimited C++
916(1): 2023/12/05(火)21:43 ID:tZxAn7Rl(1)調 AAS
>>909
GC言語でもunsafeで手動管理とかできるよ
Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ
917: 2023/12/05(火)21:59 ID:puqODfvy(1)調 AAS
>>902
>そのため複数所有者を使わざるを得ない場合に限定して用いる
複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい
Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全
C++は逆もある
>>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは
918: 2023/12/05(火)22:10 ID:vNAfxFS3(1)調 AAS
>>911
RAII自体はコストゼロ
RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる
そしてヒープ領域を所有していればヒープ解放コストがかかる
何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい
スタック領域で済ませられるならさらに望ましい
919: 2023/12/05(火)22:57 ID:iiJ5Z2H1(5/5)調 AAS
全部独り言だったりしてｗ
920: 2023/12/06(水)01:20 ID:N0N71GtG(1/7)調 AAS
メモリに展開するのにオーバーフローしてもエラーを通知しないの？
https://japan.zdnet.com/article/35212258/
言語はCらしいけどどういうプログラムなんだろう
まじでmallocしてそこにmemcpyしてるだけなんじゃないか
対策はRustで書き直せ
921: 2023/12/06(水)01:23 ID:N0N71GtG(2/7)調 AAS
たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう
どうせオフセットも手計算だろうし
922(1): 2023/12/06(水)01:40 ID:MT5mgeUa(1/6)調 AAS
>>916
＞>>909
＞GC言語でもunsafeで手動管理とかできるよ
どの言語？具体名あげてくれ。
923: 2023/12/06(水)01:58 ID:+XLnMsko(1/4)調 AAS
[gc unsafe] [🔍]
924(1): 2023/12/06(水)09:15 ID:oM0gjrfW(1/8)調 AAS
>>867-868
循環参照は？
925(2): 2023/12/06(水)09:17 ID:oM0gjrfW(2/8)調 AAS
>>867
>あらゆる本で紹介されてない
a)全ての本で紹介されていない
b)紹介された本がひとつもない
どっちの意味？念のため確認
926: 2023/12/06(水)09:18 ID:oM0gjrfW(3/8)調 AAS
>925 補足
a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある)
927: 2023/12/06(水)09:20 ID:oM0gjrfW(4/8)調 AAS
>>868
思い付いている人は大勢居る
>>865
>C++で極力Rustっぽく書く
いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ
きみ承認欲求強過ぎるね
928: 2023/12/06(水)10:53 ID:CNnXy5JV(1)調 AAS
>>922
メジャーなとこで言えばC#とかSwiftとか
929(1): 2023/12/06(水)11:45 ID:oM0gjrfW(5/8)調 AAS
>>905
やっぱりNATテーブル不良で再起動したら治るルーターじゃん
930: 2023/12/06(水)12:09 ID:4VSkBLs6(1)調 AAS
>>929
頭大丈夫か？
上下前次1-新書関写板覧索設栞歴
あと 72 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s