結局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/28(火) 14:34:16.09

今更だけどNonNullクソ便利だな

**デフォルトの名無しさん** · 2023/11/28(火) 14:49:32.02

>>751
イマイチ分からんのだがコードで書ける?

**デフォルトの名無しさん** · 2023/11/28(火) 15:14:43.92

>>632
と暇人が申しております

**デフォルトの名無しさん** · 2023/11/28(火) 15:30:47.32

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

void main() {
shared_ptr<T> ptr;
foo(ptr); //スタックにあると合法
shared_ptr<shared_ptr<T>> pptr;
foo(*pptr); //ヒープにあるとエラー
shared_ptr<T>&&& pp = ptr;
foo(*pptr); //次のスタックフレームに渡すのも合法
}

**デフォルトの名無しさん** · 2023/11/28(火) 15:32:05.10

>>755
あ、最後は
foo(pptr);
だわ。

**デフォルトの名無しさん** · 2023/11/28(火) 20:15:20.15

メモリがスタックにあるかヒープにあるかはリンカのアドレスマップと連携すればわかる
つまり欲しいなら自作すればいいのでは

**デフォルトの名無しさん** · 2023/11/28(火) 21:08:43.42

>>757
え？リンクでこねこにすればshared_ptrのカウンタを増減させなくて済むようになるんかね？

そういう最適化しているリンカとかあるの？

**デフォルトの名無しさん** · 2023/11/28(火) 21:40:34.18

さっぱり意味が分からんのだけど
もしかしてshared_ptr&&&なる存在に参照されたshared_ptr<T>だけはスタック上にTを保持する何者かに化けろと要求している？？

**デフォルトの名無しさん** · 2023/11/28(火) 21:52:40.46

何がやりたいのかさっぱりわからん

**デフォルトの名無しさん** · 2023/11/28(火) 23:17:43.17

クラスは必ずnewしないといけないと思いこんでいた昔のワイみたいな勘違いしてそう

**デフォルトの名無しさん** · 2023/11/28(火) 23:30:04.45

>>759
全然違う。
shared_ptr&&&なる存在には自動変数にあるshared_ptrだけしか代入できなくて、左辺値とかヒープにあるインスタンスを代入しようとするとコンパイル時にエラーになるだけだよ。

>>760
呼び出し元の方にあるスタックフレームに保存されている自動変数は、スタックフレームのLIFOを破壊しない限り存在を保証できる。そういう自動変数を呼び出し先から安全に参照したいだけだよ。

**デフォルトの名無しさん** · 2023/11/28(火) 23:38:15.09

>>762
自動変数にあるshared_ptrは左辺値だが

**デフォルトの名無しさん** · 2023/11/28(火) 23:41:06.97

そもそも参照に対して行えるのは代入ではなく初期化だし

**デフォルトの名無しさん** · 2023/11/28(火) 23:43:48.38

無知ばっかりでここまで話が通じないと思わなんだ
スタックやヒープの開始アドレスがどこから始まるとか気にしたことないの？
rustの悪いとこ透けて見えたわ

**デフォルトの名無しさん** · 2023/11/28(火) 23:55:41.04

Rustならそんな複雑なことする必要もなく
Rustの方が優れている
ライフタイムさえ満たせば参照先がヒープかスタックか関係なく同一コードでその参照を安全に返す関数などを書くことができる

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

言い訳ばかり達者で見苦しいスレだこと

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

>>765
>>751 や
>>755 と話繋がってないけど。
スタックやヒープの始まりは >>755 のコードでも >>751 の要件でもわからんやん。

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

どっかで身に覚えがある流れだなと思った
たぶん要件定義の時点でなんかおかしいよ
https://mevius.5ch.net/test/read.cgi/tech/1542002113/504-523

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

いまいちメリットがわからない
ヒープのオブジェクトなら渡す前に呼び出し側でチェックすべきなのではないのか

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

バカ強制矯正共生強請言語Rust

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

>>757
どのOSも汎用的に判別できる方法はない
(組み込みは除く)

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

Rust推してる香具師はスタックとヒープの違いも判ってないのか

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

>>768 ←これはひどい

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

関数の定義で、shared ptr の参照を安全に受け付ける仮引数の定義方法とかあるの？
効率化のためにインスタンスのコピーは無しの方向で。

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

>>773
スタックの頭知りたかったらコマンドライン引数のアドレス取れば？ヒープの頭知りたかったら最初にsbrk(0)すれば？

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

>>765
それでコンパイル時にエラーにできるのかい？

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

>>775
「安全に受け付ける」の定義は？
特に何をもって「安全」と言ってるのか

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

>>776
これだと実行時だわ、コンパイル時にはわからんわスマン。
ってか何でコンパイル時にスタックやヒープの先頭アドレス知りたいのかわからん。
リンクしないでなんてわかりようも無いし。

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

rustはヒープとスタックを言語的に区別してライフタイムをトラックしてるだろ
それが欲しいならrust使えで終わり
c++では汎用的には無理
そういう要望は昔からある

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

>>778
そりゃ、関数を実行している間は参照先が無効にならないことですな。

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

そもそもスタックに参照カウンタ必要か？
関数に対するスタックはプロセスに対するグローバル領域とライフタイムの考え方は同じ。
関数を抜けるまではスタックは有効だし、その関数以降に呼んだ関数が呼出元の関数を抜けた後も握り続ける状況は発生しえない
(別スレッドに共有したりヒープにCopy/Moveしない限りは)からshared_ptrにする必要がないと思うが。
つまり、

T x; // スタック
shared_ptr<T> x; // ヒープ

で型が異なるから、強引にCopy/Moveしなけりゃコンパイルエラーで検出できるし問題は起きない。

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

>>755 はいまいちよくわからんが、ポインタを受け取る関数側でスタックかヒープを判別したいんだろ
かつてそれを解決するため手法としてregion based memory managementが開発された
rustのライフタイム管理の源流

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

>>773
Rustでsafeにヒープが使われるのはBoxとVecおよびそれらが組み込まれた型のみなのでヒープかスタックか明確に区別がつく

>>780
参照になった時点でヒープかスタックかの区別なくライフタイムのみで安全に扱えるところがRustの勝因かな
スタック領域を指す参照についても関数から返してよい参照と返してはいけない参照の区別がライフタイムでなされる

**デフォルトの名無しさん** · 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
スタックの取扱いを調整すればよろし。

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