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

**デフォルトの名無しさん** · 2023/10/28(土) 13:45:00.38

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

前スレ: 結局C++とRustってどっちが良いの？ 7traits
http://mevius.5ch.net/test/read.cgi/tech/1693451813/

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/12/04(月) 00:12:41.83

Result型とかOk(T)とErr(E)のTとEが同じ場所に置かれそうだけどRVO機能するのかな
真面目に調べたことないけどあまり当てにしてない
最適化で適用されたらラッキーくらいの感覚

**デフォルトの名無しさん** · 2023/12/04(月) 01:36:48.81

>>835
スタックは常にキャッシュにのってる

**デフォルトの名無しさん** · 2023/12/04(月) 02:21:32.80

まあRustはこのまま死ぬんだからどうでもよくね？

**デフォルトの名無しさん** · 2023/12/04(月) 03:52:22.51

>>840
おまえのレスよりは重要だろ？

**デフォルトの名無しさん** · 2023/12/04(月) 04:29:02.89

>>840
お前自身がどうでもいい

**デフォルトの名無しさん** · 2023/12/04(月) 05:55:52.64

>>833-834
ハンドヘルドとはいえ、64bitレジスタ当然、メモリもギガバイト当然、ってそんなの組み込みっていうんかｗ

// てなことだと思う

**デフォルトの名無しさん** · 2023/12/04(月) 10:07:12.79

>>835
NGワードかもしれんが
stackのメリットは基本的にGCのこと気にしなくて良くなる感覚

**デフォルトの名無しさん** · 2023/12/04(月) 11:26:40.76

たまにバカでかいオブジェクトをスタックに置くやつが現れるが
スタックは一度伸びたらするスレッド死ぬまで開放されないからメモリ無駄遣いになる
組み込みやコンソールゲーム作ってるとこだとスタックに置けるオブジェクトのサイズの制限決めてるとこあると思うけどチェックがムズいよな
昔仕事でライブラリ開発したときは最大スタック消費量が仕様で決まってた
バグフィクスでもその上限超えてはならない

**デフォルトの名無しさん** · 2023/12/04(月) 12:05:08.64

>>813
そりゃ、テンプレートとかは基本ライブラリアン向けの機能で、コーダーから複雑性を隠蔽ながら高度な機能を使わせるためのものだからな。

コーダーが自作テンプレートを使わなくてはならない状況になったら、何か設計が間違っていないか注意する必要がある。
まぁc++だとそういう状況もあるから辛いけど。

**デフォルトの名無しさん** · 2023/12/04(月) 12:20:54.27

>>837
>意図的に移動しない限りコピーはされない
これは微妙すぎる
「意図的」も「移動」も恣意的過ぎるから後出し無敵じゃんけんにしかならない
コピーされないこともあるがコピーされる可能性を前提として最初から考えておくべき

**デフォルトの名無しさん** · 2023/12/04(月) 12:32:02.91

Rustのmonomorphization使った静的ポリモーフィズムと同じようなことしたければC++はテンプレート必須だから
ハイレベルのコードしか書かないアプリケーションプログラマーでも普通に使う必要があるでしょ

**デフォルトの名無しさん** · 2023/12/04(月) 13:13:30.82

>>845
そういやスタックは一度伸びたら伸びっぱなしだったな
これ傍から見たらメモリリークにも見えるし
何でもスタックはあかんのじゃないか

**デフォルトの名無しさん** · 2023/12/04(月) 13:29:26.93

誰からも指摘されずにどんどん明後日の方向に向かって行っているのは見てる分には面白い

どうか第2の毛の壁と化しませんように
南無阿弥陀仏

**デフォルトの名無しさん** · 2023/12/04(月) 13:38:09.73

>>849
スタックの取扱いを調整すればよろし。

コールスタックとデータスタックを分けてデータスタックをメモリブロックにするとか、大きいのはマネージドヒープに置くようにするとか。
だんだんヒープに近くなるからスタックのメリットは無くなるけど。

**デフォルトの名無しさん** · 2023/12/04(月) 19:31:46.91

コードをよりコンパクトな短文にしようと追求したらテンプレートを使うようになるのはごく当たり前だよ

**デフォルトの名無しさん** · 2023/12/04(月) 19:42:38.90

>>835
モダンなC++もそれだぞ

class Hoge {
private:
std::shared_ptr<HogeInternal> hoge;
};

Hogeは常にスタックに割り当てる
実際のオブジェクトはHogeInternalで実装する
こうしておけばめちゃくちゃ安全になる

**デフォルトの名無しさん** · 2023/12/04(月) 19:56:42.31

なんで馬鹿はshared_ptr使いたがるんだろう
生ポでいいだろ

**デフォルトの名無しさん** · 2023/12/04(月) 20:13:20.11

3/5/0則を知らないもっと馬鹿なやつがdelete用のデストラクタだけ実装して
事故が多発したからでは

**デフォルトの名無しさん** · 2023/12/04(月) 20:18:13.44

>>853
それはHogeInternalがヒープ領域に置かれてしまいスタック領域の利用ではない
さらに参照カウントのオーバーヘッドもある

**デフォルトの名無しさん** · 2023/12/04(月) 20:23:01.45

C++、雰囲気で書いたらすぐに壊れるくせに文法がどんどん増えていくのついていけねえわ
どんだけの勉強コストを一つの言語に払わせる気だよ
C++に人生捧げて他のこと何も出来ない無能だけが扱える言語となりつつある

**デフォルトの名無しさん** · 2023/12/04(月) 20:27:01.58

3/5/0則みたいな言語の欠陥に疑問を持たなくなったらもう終わり

**デフォルトの名無しさん** · 2023/12/04(月) 20:31:26.59

>>856
いだから置くんだよ
伝わってないみたいだから説明するとHogeに直接実装しないってことを言ってる
間接参照を一段挟むのよ
こうすることでコピーしまくっても問題ないヒープに確保されたオブジェクトができる
多少オーバーヘッドは生まれるがめちゃくちゃ安全性は上がるんよ

**デフォルトの名無しさん** · 2023/12/04(月) 20:32:20.03

そそ、難解な概念使いこなせるのはすごいけど、会社でマウントとれるだけ
世の中が求めてるのはそこじゃない。

**デフォルトの名無しさん** · 2023/12/04(月) 20:59:36.17

>>859
Rustを使えばヒープではなくスタック領域に確保してそこへの参照をオーバーヘッドなしで安全に使えるよ
その点がRustとC++の差

**デフォルトの名無しさん** · 2023/12/04(月) 21:10:50.41

>>859
ヒープを使うというオーバーヘッドに加えて
参照カウントを使うというオーバーヘッドまで加わる
もちろん各々が不可欠な場合や両方が不可欠な場合もあるがその前提や吟味をせずに
まともなプログラマーがとる選択肢ではない

**デフォルトの名無しさん** · 2023/12/04(月) 21:14:53.25

>>862
嫌だから共有が必要な場合って書いてあるだろ
日本語読める？
共有じゃないならstd::unique_ptrでもいいよ

**デフォルトの名無しさん** · 2023/12/04(月) 21:15:11.88

Hogeに実装しないことでコピー時のオーバーヘッドを防ぐ
さらに個別にコピーのことを考える必要性がなくなる
HogeInternalのコピーコストだけで済むため高速
shared_ptrは安全にコピー可能
データは共有できメモリ管理も自動で行われる
ヒープにとらなきゃいけなくて共有する可能性があるオブジェクトはこのパターンで実装してください
マジで何も考えなくていいから

**デフォルトの名無しさん** · 2023/12/04(月) 21:18:26.98

>>861
C++で極力Rustっぽく書くにはどうすべきかを突き詰めたらこうなった
褒めてくれ

**デフォルトの名無しさん** · 2023/12/04(月) 21:25:29.71

>>863
Rustなら参照の共有はヒープを使わずスタックに置いてあるものに対しても安全に可能です
もちろん参照カウンタは必要ありません
ちなみにRustでC++のshared_ptrに相当するRc/Arcを必要とするのはもっと限定された状況で所有の共有が必要となる時のみです

**デフォルトの名無しさん** · 2023/12/04(月) 21:32:42.16

新たな間接参照でラップすることであたかも普通の変数を作るかのようにヒープに値を置ける
このパターンめちゃくちゃ有用なんだがなぜあらゆる本で紹介されてないんだ？

**デフォルトの名無しさん** · 2023/12/04(月) 21:35:03.72

コロンブスの卵だわ
誰もが思いつきそうで思いつかなかった

**デフォルトの名無しさん** · 2023/12/04(月) 21:39:30.12

>>866
まあその辺はさすがRust

**デフォルトの名無しさん** · 2023/12/04(月) 21:41:03.87

本気でRustに寄せるならunique_ptrの方がいいな
コンパイラが助けてくれないから死にそうだけど
とりあえず循環参照だけは気を付けてくれ

>>867
目的はちょっと違うけどPimplってイディオムがある

**デフォルトの名無しさん** · 2023/12/04(月) 21:54:58.33

継承じゃ無くて、包含して各メソッドをバトン渡しすれば良くね？

**デフォルトの名無しさん** · 2023/12/04(月) 22:45:48.75

>>867
他のやつも書いてるけどpimplな
20年前から知られている
ひたすらdelegate関数を書くのがだるい
使う側がshared_ptrで包むというルールのほうが楽

**デフォルトの名無しさん** · 2023/12/04(月) 23:15:56.57

>>872
>ひたすらdelegate関数を書くのがだるい
書かねば良いのでは?

**デフォルトの名無しさん** · 2023/12/04(月) 23:53:40.38

>>867
間接参照でいいならわざわざクラスでラップしなくてもshared_ptrそのものでいいように思うんだが
shared_ptr<HogeInternal>で扱うより
ラップしたHogeで扱ったほうがいいメリットって何？

**デフォルトの名無しさん** · 2023/12/05(火) 00:09:25.25

mallocでメモリ確保するの気持ちイィ🥴

**デフォルトの名無しさん** · 2023/12/05(火) 00:55:04.31

>>872
20年前にこの概念が存在していたのか
当時はauto_ptrとかオレオレメモリ管理モジュールだったとは思うけど

**デフォルトの名無しさん** · 2023/12/05(火) 00:58:42.15

>>872
ライブラリとして定期したい場合はshared_ptrで常に包むルールを強制するのも難しいとかかな

**デフォルトの名無しさん** · 2023/12/05(火) 04:45:21.81

delegate指定子欲しいよな。
クラスor変数でまとめて指定できればなお良し。

**デフォルトの名無しさん** · 2023/12/05(火) 05:43:53.62

それってRustのDeref？

**デフォルトの名無しさん** · 2023/12/05(火) 08:01:23.94

std::byteを使ってみた結果
危険な計算ができるのがC/C++を使う理由という結論になった

**デフォルトの名無しさん** · 2023/12/05(火) 08:50:09.72

一人で何役やってるの？

**デフォルトの名無しさん** · 2023/12/05(火) 09:49:41.30

>>881
数えてみろよ

**デフォルトの名無しさん** · 2023/12/05(火) 10:22:23.63

>>877
Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは？

**デフォルトの名無しさん** · 2023/12/05(火) 10:50:40.33

>>879
delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。

参照外しとかして型を変えるのはNG。

**デフォルトの名無しさん** · 2023/12/05(火) 11:56:35.63

Rustのdelegate!のようなことがC++ではまだ出来ないということか
汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな

**デフォルトの名無しさん** · 2023/12/05(火) 13:26:22.00

>>882
こういうキチガイ対策にワッチョイ必要かもな

**デフォルトの名無しさん** · 2023/12/05(火) 13:34:36.87

>>882
きっしょw

**デフォルトの名無しさん** · 2023/12/05(火) 14:18:15.60

>>884
スマートポインタなのだから
Derefにより自動的に参照できれば十分だろ

**デフォルトの名無しさん** · 2023/12/05(火) 14:23:46.88

ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ

**デフォルトの名無しさん** · 2023/12/05(火) 14:24:46.44

×立てたってところで
○立てたところで

**デフォルトの名無しさん** · 2023/12/05(火) 14:31:18.82

Adaptorにだけ執拗にこだわるオジもアレだか
Adaptorも知らずにDerefを勧めるオジは論外

**デフォルトの名無しさん** · 2023/12/05(火) 14:58:30.60

>>883
ユーザーに返す型では流石に気持ち悪いと思うなあ
C++難し過ぎるだろ
選択肢が多過ぎる
かといって安全でもない
もうRust使わせてくれ

**デフォルトの名無しさん** · 2023/12/05(火) 15:21:39.57

>>892
別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない
(生ポインタはありえない)
だからそこを気持ち悪いと言っても仕方ない

**デフォルトの名無しさん** · 2023/12/05(火) 15:51:48.29

>>892
Rustでもそこは同じだと思うよ
ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある
シンプルなケースなら前者の方が圧倒的に使いやすい
内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ
要はラップするだけの付加価値があるかどうか

**デフォルトの名無しさん** · 2023/12/05(火) 15:52:25.13

>>854
馬鹿は平気で二重に解放したりする
全然気にしないから馬鹿なんだけどね

**デフォルトの名無しさん** · 2023/12/05(火) 16:00:15.02

>>854
いやいやいやいやw

**デフォルトの名無しさん** · 2023/12/05(火) 16:26:52.90

リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない？

**デフォルトの名無しさん** · 2023/12/05(火) 16:45:36.42

>>889
えー

**デフォルトの名無しさん** · 2023/12/05(火) 16:47:29.78

ならない
リアルタイム系アプリでGCは困る

**デフォルトの名無しさん** · 2023/12/05(火) 17:17:38.64

循環参照で発生するリークを検出するか放置するか
あるいは循環参照を回避するか
それが問題だ

**デフォルトの名無しさん** · 2023/12/05(火) 17:29:27.24

>>899
マークスウィープの話をしてないぞ
リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる

**デフォルトの名無しさん** · 2023/12/05(火) 17:59:20.81

手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない
手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト

その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる
そのため複数所有者を使わざるを得ない場合に限定して用いる

**デフォルトの名無しさん** · 2023/12/05(火) 18:13:07.15

>>902
Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ

**デフォルトの名無しさん** · 2023/12/05(火) 18:43:14.63

>>894
気持ち的にはラップしたいかなあ

**デフォルトの名無しさん** · 2023/12/05(火) 19:04:48.69

全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/

Rustを使えばいいじゃない

**デフォルトの名無しさん** · 2023/12/05(火) 19:13:25.15

IBMだったらJavaだったのに

**デフォルトの名無しさん** · 2023/12/05(火) 19:18:25.05

積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ

**デフォルトの名無しさん** · 2023/12/05(火) 19:24:31.25

Cとの互換性

**デフォルトの名無しさん** · 2023/12/05(火) 19:32:43.32

>>897
問題はGC言語は *常に* GC機能ありなところ。

**デフォルトの名無しさん** · 2023/12/05(火) 19:40:36.09

>>907
オブジェクト指向ｗ

**デフォルトの名無しさん** · 2023/12/05(火) 20:04:51.38

リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな
mallocはプログラムの最初に一回呼ぶ以外は許されない

**デフォルトの名無しさん** · 2023/12/05(火) 20:31:30.51

>>907
組み込み系でオブジェクトやりたい人
あと意図的に悪意あるコードを仕込む人とか。

**デフォルトの名無しさん** · 2023/12/05(火) 21:15:38.20

やりたいことが出来るのが一番の理由
アンリミテッドが魅力

**デフォルトの名無しさん** · 2023/12/05(火) 21:36:14.43

参照カウントて結構コストあったよな……と探したら解説見つけた。
yamasa.hatenablog.jp/entry/2021/01/29/012525

昔は並列処理と相性悪いと言われていたけど、今はどうかね？

**デフォルトの名無しさん** · 2023/12/05(火) 21:36:19.50

++C Unsafety Unlimited C++

**デフォルトの名無しさん** · 2023/12/05(火) 21:43:08.45

>>909
GC言語でもunsafeで手動管理とかできるよ
Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ

**デフォルトの名無しさん** · 2023/12/05(火) 21:59:57.96

>>902
>そのため複数所有者を使わざるを得ない場合に限定して用いる
複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい
Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全
C++は逆もある
>>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは

**デフォルトの名無しさん** · 2023/12/05(火) 22:10:46.45

>>911
RAII自体はコストゼロ
RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる
そしてヒープ領域を所有していればヒープ解放コストがかかる
何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい
スタック領域で済ませられるならさらに望ましい

**デフォルトの名無しさん** · 2023/12/05(火) 22:57:00.41

全部独り言だったりしてｗ

**デフォルトの名無しさん** · 2023/12/06(水) 01:20:30.01

メモリに展開するのにオーバーフローしてもエラーを通知しないの？
https://japan.zdnet.com/article/35212258/

言語はCらしいけどどういうプログラムなんだろう
まじでmallocしてそこにmemcpyしてるだけなんじゃないか
対策はRustで書き直せ

**デフォルトの名無しさん** · 2023/12/06(水) 01:23:15.09

たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう
どうせオフセットも手計算だろうし

**デフォルトの名無しさん** · 2023/12/06(水) 01:40:45.31

>>916
＞>>909
＞GC言語でもunsafeで手動管理とかできるよ

どの言語？具体名あげてくれ。

**デフォルトの名無しさん** · 2023/12/06(水) 01:58:21.86

[gc unsafe] [🔍]

**デフォルトの名無しさん** · 2023/12/06(水) 09:15:07.04

>>867-868
循環参照は？

**デフォルトの名無しさん** · 2023/12/06(水) 09:17:14.31

>>867
>あらゆる本で紹介されてない

a)全ての本で紹介されていない
b)紹介された本がひとつもない

どっちの意味？念のため確認

**デフォルトの名無しさん** · 2023/12/06(水) 09:18:07.12

>925 補足
a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある)

**デフォルトの名無しさん** · 2023/12/06(水) 09:20:39.56

>>868
思い付いている人は大勢居る

>>865
>C++で極力Rustっぽく書く

いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ
きみ承認欲求強過ぎるね

**デフォルトの名無しさん** · 2023/12/06(水) 10:53:51.94

>>922
メジャーなとこで言えばC#とかSwiftとか

**デフォルトの名無しさん** · 2023/12/06(水) 11:45:54.12

>>905
やっぱりNATテーブル不良で再起動したら治るルーターじゃん

**デフォルトの名無しさん** · 2023/12/06(水) 12:09:32.50

>>929
頭大丈夫か？

**デフォルトの名無しさん** · 2023/12/06(水) 12:31:44.18

型推論の是非を問いたい
書くのは楽かもしれないが読みにくくね？
型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる
読みやすさを優先すべきだと思うがどうだろう
IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな

**デフォルトの名無しさん** · 2023/12/06(水) 12:44:38.03

>>931
ややこしい型の手書きとか効率悪化の元だから駄目。

せいぜいIDEに型のコメントを自動生成させるくらいまでだな。手動は更新されなくなってバグの温床になる。

**デフォルトの名無しさん** · 2023/12/06(水) 12:46:06.06

>>931
けっこう同意。
変数初期化ではリテラルでの場合だけ型推論利用して、そうでなければ型書いちゃうことも多い。

**デフォルトの名無しさん** · 2023/12/06(水) 12:51:11.58

>>932
＞手動は更新されなくなってバグの温床になる。

型変わったらコンパイル通らないし、型明示がバグの温床になるってのは無い。
修正の手間が増えるってのはわかる。

**デフォルトの名無しさん** · 2023/12/06(水) 12:54:09.75

複雑な型名を知る必要がない場合も多い
例えばRustなら関数の引数型も返り型でも具体的な型名を書かずに
impl Trait名　と使う機能のトレイト名だけを指定したり

**デフォルトの名無しさん** · 2023/12/06(水) 12:56:26.38

>>934
c++はスライシングあるからエラーにならない例外もある。
レアケースだけど。

**デフォルトの名無しさん** · 2023/12/06(水) 13:09:40.96

同じ情報を二重に書くのはプログラマなら普通疑問に思う