[過去ﾛｸﾞ] 結局C++とRustってどっちが良いの？ 8traits (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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
頭大丈夫か？
931(2): 2023/12/06(水)12:31 ID:3kI3ay52(1/5)調 AAS
型推論の是非を問いたい
書くのは楽かもしれないが読みにくくね？
型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる
読みやすさを優先すべきだと思うがどうだろう
IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな
932(2): 2023/12/06(水)12:44 ID:lEEu+DT0(1/2)調 AAS
>>931
ややこしい型の手書きとか効率悪化の元だから駄目。
せいぜいIDEに型のコメントを自動生成させるくらいまでだな。手動は更新されなくなってバグの温床になる。
933: 2023/12/06(水)12:46 ID:MT5mgeUa(2/6)調 AAS
>>931
けっこう同意。
変数初期化ではリテラルでの場合だけ型推論利用して、そうでなければ型書いちゃうことも多い。
934(1): 2023/12/06(水)12:51 ID:MT5mgeUa(3/6)調 AAS
>>932
＞手動は更新されなくなってバグの温床になる。
型変わったらコンパイル通らないし、型明示がバグの温床になるってのは無い。
修正の手間が増えるってのはわかる。
935: 2023/12/06(水)12:54 ID:B4jpx9xe(1)調 AAS
複雑な型名を知る必要がない場合も多い
例えばRustなら関数の引数型も返り型でも具体的な型名を書かずに
impl Trait名 と使う機能のトレイト名だけを指定したり
936: 2023/12/06(水)12:56 ID:lEEu+DT0(2/2)調 AAS
>>934
c++はスライシングあるからエラーにならない例外もある。
レアケースだけど。
937(1): 2023/12/06(水)13:09 ID:6EzLMFr7(1/5)調 AAS
同じ情報を二重に書くのはプログラマなら普通疑問に思う
938(1): 2023/12/06(水)13:12 ID:N0N71GtG(3/7)調 AAS
>>924
コピー時はweak_refで渡すので良いかと思うのだが
939: 2023/12/06(水)13:14 ID:N0N71GtG(4/7)調 AAS
>>925
普通に考えてaじゃないの？
なんで紹介とか出てくるんだ？
940(1): 2023/12/06(水)13:17 ID:3kI3ay52(2/5)調 AAS
>>937
ある程度の重複さによってミスを早期発見できる効果があるから一概にそうはいえないぞ
941: 2023/12/06(水)13:31 ID:UHi6Tpqq(1)調 AAS
俺のプログラムにバグがあるのは
俺がまだ本気出してないだけだから
942: 2023/12/06(水)13:38 ID:+XLnMsko(2/4)調 AAS
どれだけスレが進行しても客観的な基準が示されず
主観バトルを発生させ続け
留まるところを知らない概念
可読性
943: 2023/12/06(水)13:40 ID:uGBP6FLN(1/3)調 AAS
>>938
いやそれだとshared_ptrの意味ないから
shared_ptr使う限りは本質的には解決は難しい
それは生でshared_ptr使う場合も同じ
get_weakというメソッドでweak_refでラップして返すメソッドを提供するとかだろう
944(1): 2023/12/06(水)13:44 ID:uGBP6FLN(2/3)調 AAS
全銀のシステムこの規模で低レイヤーのメモリ操作しまくるのにC使ってるのマジで狂気としか思えないな
コードレベルのユニットテストもないのだろうし
絶対こういうこと起きるやん
945(2): 2023/12/06(水)13:55 ID:6EzLMFr7(2/5)調 AAS
>>940
保守できなくなるから必ず避けるべき
946(1): 2023/12/06(水)14:04 ID:3kI3ay52(3/5)調 AAS
>>945
プログラミング言語自体、ある程度の冗長性があるようにデザインされている
たからこそコンパイルエラーという現象が起こる
そもそもテストを書くという行為が重複した作業なのだけどやるだろ？
仕様変更したら書き直しなのは仕方ない
上下前次1-新書関写板覧索設栞歴
あと 56 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s