結局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/11/29(水) 12:57:35.03

例が微妙だな。直しておくか。

void foo(shared_ptr<T>&&& p)
でshared_ptr&&&が自動変数専用参照だとすると、

shared_ptr<T> bar()

void main() {
shared_ptr<T> ptr;
foo(ptr); //自動変数だと合法
foo(bar()); //自動変数でないとエラー
}

void foo(shared_ptr<T>&&& p) {
baz(p); //次のスタックフレームに渡すのも合法
}

**デフォルトの名無しさん** · 2023/11/29(水) 13:05:45.44

>>785
shared_ptr<T>を使うから意味が不明なんだよ
Tが置かれる場所がスタックかヒープかなんだろ？

**デフォルトの名無しさん** · 2023/11/29(水) 13:32:40.14

void foo(T& p){}
void foo(shared_ptr<T>& p){static_assert}

**デフォルトの名無しさん** · 2023/11/29(水) 13:33:08.54

>>768
なんやこれ
頭がおかしくなりそう

**デフォルトの名無しさん** · 2023/11/29(水) 13:37:19.41

>>773
スタックとヒープの違いが分かってなくても使えるなんて、なんて素晴らしい言語なんだ

**デフォルトの名無しさん** · 2023/11/29(水) 13:52:43.41

もういいよ
議論するレベルになってない
引っ掻き回したいだけだろ
この話題終わり
ゴミだから

**デフォルトの名無しさん** · 2023/11/29(水) 14:48:01.22

>>786
違う。
「shared ptr」の置かれている場所がスタックかヒープか。この場合だとTはヒープ。
>>785はとりあえず「shared ptrが」自動変数にある場合だけエラーにならないのを想定。

**デフォルトの名無しさん** · 2023/11/29(水) 15:04:52.17

はい終わり終わり

**デフォルトの名無しさん** · 2023/11/29(水) 15:22:50.48

>>791
shared_ptrの参照カウントの操作を省きたいならshared_ptrの参照渡すか生ポインタ渡せばいいだろ
それかrustにしろ

**デフォルトの名無しさん** · 2023/11/29(水) 15:29:56.33

「lvalueよりさらに限定された値カテゴリを作って、それだけを指せる参照を導入したい」という欲求

もしかして: ライフタイム

**デフォルトの名無しさん** · 2023/11/29(水) 15:56:42.98

ヒープを排除したいのは参照してる間にfree/deleteされるのを気にしてるからかな
Rustだとライフタイムというよりborrow checkで解決してる問題

**デフォルトの名無しさん** · 2023/11/29(水) 16:40:54.30

>>795
そこでborrow checkerが具体的にしていることがライフタイムの妥当性(やミュータビリティの妥当性など)

**デフォルトの名無しさん** · 2023/11/29(水) 18:22:15.98

>>781
ポイントしてる先がどうなってるかは関係なくてshared_ptr自体がスタック上で生きていれば「shared_ptrへの参照」は無効にならないということを「安全」だと言ってるという理解でいい？

**デフォルトの名無しさん** · 2023/11/29(水) 20:22:08.97

>795 >797
そういう話。
RustだとRc<T>の参照をbollow checkerで(たしか)安全に管理できたけど、c++はshared ptr の参照なんて気にもしないで破棄するから、せめて自動変数に置くことを強制しできればちょっとだけ安全に効率化できるのにな、ぐらいの話。

**デフォルトの名無しさん** · 2023/11/29(水) 20:54:47.61

RustのRcもC++のshared_ptrも参照でやり取りするより
Rc本体をclone（C++なら値渡しでコピー）した方が使いやすいと思う

中身じゃなく本体を参照渡しするなら参照カウンタ増えないしRc（shared_ptr）使う意味がなさそう
shared_ptrは元データが破棄されてもコピーが生き残ることに意味があるわけで
この例でshared_ptrを使われると話がややこしくなる

**デフォルトの名無しさん** · 2023/11/29(水) 22:26:34.34

>>798
なるほどそういうことならAST的なものに対してカスタムルールを定義できる静的解析ツールみたいなもので頑張ればチェックはできそう

ただポイント先が途中で変化しても安全と言えるかどうか微妙
Arc/Rcはownerが複数いる場合はポイント先が変更されないことも保証されてる

**デフォルトの名無しさん** · 2023/11/30(木) 12:27:38.75

ライフタイムチェックが今のRustと同じレベルになるのは早くてもC++32以降なので過度に期待せず気長にお待ち下さい。

**デフォルトの名無しさん** · 2023/11/30(木) 13:55:26.66

>>791
その理屈だと
>>784 も頓珍漢なこと言ってる

**デフォルトの名無しさん** · 2023/11/30(木) 13:57:58.44

要するに
>>782
で話は終わってる

**デフォルトの名無しさん** · 2023/11/30(木) 14:51:08.28

的はずれなことを書いてる自覚がないとはな
複オジ(>>784)のほうが多少自覚してるだけマシかもしれんぞ

**デフォルトの名無しさん** · 2023/11/30(木) 15:21:08.01

>>800
自作でやるならかなり大変で、自作言語作るのと工数変わらないかも。
それならRust使ったほうが楽かね。

**デフォルトの名無しさん** · 2023/11/30(木) 16:35:34.05

いや服おじは論外

**デフォルトの名無しさん** · 2023/12/01(金) 20:56:33.56

>>801
サポートするとC++ではなくなってしまう
別言語を同居させたようになり混乱が増す

**デフォルトの名無しさん** · 2023/12/02(土) 00:20:14.03

C++はもうテンプレートで道を一度踏み外してる外道だから今更だよ

**デフォルトの名無しさん** · 2023/12/02(土) 21:13:09.29

Javaからプログラム始めたからC++の静的ポリモーフィズムやるconceptの制約がわかりにくすぎて使いこなせん
C++20のconceptを使いこなせてる猛者さん、果たしてスレにおるのかね

**デフォルトの名無しさん** · 2023/12/02(土) 21:29:52.21

C++で継承をやろうとするのが間違いなんだよね😇
テンプレートはゴミ！
ゴミなんです！

**デフォルトの名無しさん** · 2023/12/02(土) 22:01:16.75

C++使ってるけど継承もテンプレートも使ってないな

**デフォルトの名無しさん** · 2023/12/03(日) 11:30:00.35

つ
ま
ん
ね

**デフォルトの名無しさん** · 2023/12/03(日) 13:55:04.97

最近新プロジェクトでC++書かなきゃいけなくてRust使いたがったが
外部システムやライブラリとの絡みで仕方なくC++を使うことになったのだけど

std::shared_ptr
std::weak_ptr
std::move
ムーブ代入演算子
ムーブコンストラクタ
enum class
constexpr(主に設定値のテーブル初期化などに使う)

新しい要素だとマジでこれだけしか使ってなかったよ
継承なしテンプレートなし
外部ライブラリとしてonetbbとminimalloc使ってるだけ
これだけでもそこそこモダンなプログラミングができる
あと足りないのはライフタイムだけかな
C++にそれがきたらRustはいらないけど果たしていつになるのか

**デフォルトの名無しさん** · 2023/12/03(日) 14:26:32.44

shared_ptr使ったならテンプレートなしは言いすぎかな
自作テンプレートなしってところか
テンプレートはライブラリとか裏方向けの要素だからアプリ開発ではあまり使わないかも

**デフォルトの名無しさん** · 2023/12/03(日) 14:31:19.88

は?

**デフォルトの名無しさん** · 2023/12/03(日) 16:51:09.16

>>813
STLって何の略だか知ってる？

**デフォルトの名無しさん** · 2023/12/03(日) 17:00:48.99

>>815
は？

**デフォルトの名無しさん** · 2023/12/03(日) 17:02:40.23

自作テンプレートって意味だろ
文脈理解できないんだな
全部書かなきゃ理解できないタイプ？

**デフォルトの名無しさん** · 2023/12/03(日) 17:43:27.43

>>818
はww

**デフォルトの名無しさん** · 2023/12/03(日) 17:57:09.24

このスレはﾜｯﾁｮｲ必要だねえ
次スレの1の本文先頭に以下を追加しといてね
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)

**デフォルトの名無しさん** · 2023/12/03(日) 18:05:13.75

>>818
はww

**デフォルトの名無しさん** · 2023/12/03(日) 19:07:22.56

わかる裏方向けっていうか、裏方モードのときだね
アプリ開発してる最中に、ややこしいクラスライブラリを内製してる…ばっかりでもない

**デフォルトの名無しさん** · 2023/12/03(日) 19:10:50.45

人殴ったりはしないけど、アホなこと書いたりはしちゃうんだよねえ(無知を晒す自爆型)
1日経ったらチャラになってくれたほうが気は楽

**デフォルトの名無しさん** · 2023/12/03(日) 19:13:42.60

次スレ自体いらんが

**デフォルトの名無しさん** · 2023/12/03(日) 19:55:23.02

絶対必要なモノなんてない俺すら不要物

**デフォルトの名無しさん** · 2023/12/03(日) 20:29:50.68

俺スラ？
は？
www

**デフォルトの名無しさん** · 2023/12/03(日) 20:33:01.48

>>819
効いてる効いてるw

**デフォルトの名無しさん** · 2023/12/03(日) 21:02:12.27

じゃあベアメタルではヒープとスタックはどうなるの？

**デフォルトの名無しさん** · 2023/12/03(日) 22:33:53.82

まだいたのかベアメタル

**デフォルトの名無しさん** · 2023/12/03(日) 22:41:05.20

マイコンいろいろ買ってみたけど、結局デスクトップばかりいじってる俺、なんとも言えずｗ

**デフォルトの名無しさん** · 2023/12/03(日) 22:55:35.48

RVOにより呼び出し元でスタック領域を確保できつつ
Rustのようにスタック領域に対しても自動的にライフタイム管理ができていれば
コストの高いヒープ領域利用を可能な限り減らしつつ
スタック領域を指す参照(ポインタ)を返したり他へ埋め込んだりしていても安全に使える
というシンプルな話

**デフォルトの名無しさん** · 2023/12/03(日) 23:01:41.36

C++もRustもベアメタルという土俵で真価を問われると思うよ
小型軽量ガジェットでAIを高速に処理出る言語に需要があると思ってる。

**デフォルトの名無しさん** · 2023/12/03(日) 23:04:45.84

ねーわw
ガジェットww

**デフォルトの名無しさん** · 2023/12/03(日) 23:06:04.65

ガジェットじゃなくて組み込みデバイスと言え

**デフォルトの名無しさん** · 2023/12/03(日) 23:16:00.90

Rust使ってるとヒープ領域はスタック上のどこかの変数の運命共同体って感覚になるから
ヒープだからコストが高いって言われると何か違和感がある
Box（ヒープ配置）にするかしないかでたまに迷うけど

【スタック領域】
・サイズが固定
・確保、解放のオーバーヘッドがない
・スタック上で頻繁にコピーされるからでかいと不利

【ヒープ領域】
・サイズが自由
・確保、解放のオーバーヘッドがある
・基本的に移動しないからでかいときに有利

みたいなイメージで使い分けてる
スタック／ヒープだから安全／危険とかは特にないな

**デフォルトの名無しさん** · 2023/12/03(日) 23:16:28.96

明日仕事がいやでストレスためてそうやなw

**デフォルトの名無しさん** · 2023/12/03(日) 23:38:17.10

>>835
>>・スタック上で頻繁にコピーされるからでかいと不利

意図的に移動しない限りコピーはされない
ヒープと同じで基本的に移動の必要はない
唯一コピーが起きそうに見える関数返しによる初期化はRVOによりコピーされない
ヒープと同じで確保後はそこへの参照のみ扱うため移動コピーは起きない

**デフォルトの名無しさん** · 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。