結局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/25(土) 09:02:19.65

>他人の書いたC++ライブラリがめっちゃメモリリークする

某OSのAPIのことですね判ります

**デフォルトの名無しさん** · 2023/11/25(土) 09:47:04.81

>>685
サブタイピング時に
上位の型が持つ実装コードの一部が
下位の型と共有されること

**デフォルトの名無しさん** · 2023/11/25(土) 21:29:31.59

嘘オジと複オジは撃沈されたようだな

**デフォルトの名無しさん** · 2023/11/26(日) 15:19:59.23

OSにバグがあって後処理をしてもOSがリソースを掴みっぱなしになるといった経験はないだろうか。
そういった場合そのリソースを使う箇所だけ子プロセスとして隔離し、使い終わったらそのプロセスを終了する事でリソースを完全に開放させることが可能だ。
このプロセスの隔離はかなり万能な解決方法で、納期が短くて怪しいと思っても修正が困難なケースにも応用可能だ。
まあ要するにリークを疑われる場合一旦別プロセスにすれば必ず開放されるからリークは必ずしも怖くないよって話。

**デフォルトの名無しさん** · 2023/11/26(日) 15:30:13.25

と、御社の現お取引先ホームページにありますね。
弊社はRust採用実績十分、リークは原則としてありません

**デフォルトの名無しさん** · 2023/11/26(日) 16:02:44.80

>>687
いい定義だな

**デフォルトの名無しさん** · 2023/11/26(日) 16:21:23.35

Rustはモダンな言語の一つなので
その定義でもRustは実装継承を持たずきちんと排除している

**デフォルトの名無しさん** · 2023/11/26(日) 18:06:50.18

結局、c++が最狂ってことでいいな？

**デフォルトの名無しさん** · 2023/11/26(日) 18:08:00.70

>>618
c++が最凶最悪

**デフォルトの名無しさん** · 2023/11/26(日) 18:37:35.88

>>689
OSのバグならアプリのプロセスを落としたところでリソースが解放されるとは限らない
プロセス落とすのはどちらかと言うとアプリのバグに対処するため

**デフォルトの名無しさん** · 2023/11/26(日) 18:49:55.09

>一旦別プロセスにすれば必ず開放される

doubt

**デフォルトの名無しさん** · 2023/11/26(日) 19:14:33.38

すくなくともWindowsは長期間起動し続けると空きメモリが減っていく
OSが意図的に開放せずにキャッシュしてるのかリークなのかは分からないが

**デフォルトの名無しさん** · 2023/11/26(日) 19:39:37.59

>>689
それ本当にOSのバグ？ｗ

**デフォルトの名無しさん** · 2023/11/26(日) 19:41:06.05

>>689
子プロレス切り離しが大仕事だろ
そこで別のバグが大量に入り込む
全然簡単な話じゃない
お前言うだけでやったことないだろ

**デフォルトの名無しさん** · 2023/11/26(日) 19:44:09.20

>>689
きっしょ

**デフォルトの名無しさん** · 2023/11/26(日) 22:37:51.44

俺が遭遇したのは2件で、どちらもOSの不具合という結論だよ
MSのナレッジに残ってるかもしれないがどっちもプロセスを終了するしか解決策が示されなかった
>>699
こういう理不尽に遭遇して回避策が示されたなら大仕事でもやらざるを得ないと思うけどね
別に難しいって程でもないし

**デフォルトの名無しさん** · 2023/11/26(日) 22:48:32.77

そういや別件でOSが設定しているタイムアウト値を待てない場合も別プロセスにして回避した事がある
この板って年寄りばかりだろうしWindowsのプログラミング長年やってれば何度かそういう事に遭遇するんじゃないの

**デフォルトの名無しさん** · 2023/11/26(日) 23:01:37.86

あのね、年寄りが真面目に答えてやるとOSの観点から言うと
windowsとLinuxじゃプロセスの考え方が結構違ってて
Linuxの場合、バックグラウンドプロセスっていうのは普通に使われまくってるの
いわゆるプロセスのクローンだから扱いが楽
シェルから作れるし

一方windowsではexeなんでクソ重い上に扱いが面倒
データ共有やプロセス間通信も一苦労だ
だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う
windowsにおいてスレッドの方が軽い

一方Linuxではスレッドもプロセスも本質的に同じ
(カーネルの構造体thread_structはプロセス生成の時も使う)

よってプログラミングモデルがだいぶ違うため
どうすべきか？はかなり違う

以上がwindowsでもLinuxでも並行処理を書いてきた俺の感想

**デフォルトの名無しさん** · 2023/11/26(日) 23:12:09.99

Windowsはプロセスもスレッドも、互換性チェックみたいのが重厚らしく超高コスト
さらに、セキュリティソフトが走ってるのが当たり前の世界なので、ファイルハンドルも高コスト
なんでもWSL2でやったほうが軽い? らしい

てことで、コルーチンはいいぞｗ

**デフォルトの名無しさん** · 2023/11/26(日) 23:30:18.11

Rustの東京を使えばデフォルトでCPUのコアスレッド数をフル活用してコルーチンを何万も同時に動かせますものね

**デフォルトの名無しさん** · 2023/11/27(月) 00:37:45.36

Elixir は、10万もの小プロセスを起動できる

Go の並行処理も、mattn の本に書いてあるけど、
C で、100スレッドを起動したら、
CPU 使用率が高く、12秒も掛かったが、

Goで100 goroutine を起動したら、
6スレッドしか起動せず、9秒で済んだ

Goの方が、CPUコアを効率的に使える

**706** · 2023/11/27(月) 00:48:36.74

とにかく、スレッドを起動したらダメ！

CPU コアや時間の大半が、起動処理に使われるから

**デフォルトの名無しさん** · 2023/11/27(月) 00:59:58.17

とはいえコルーチンって使い所が難しいのよ
流行りそうで流行らないのがその理由
結局「本当の並列性が必要ないようなすぐ終わる処理を大量にする」ユースケースにしか使えないから

こういう処理ってあまりないことに気がつく
まず真の並列性が必要となる数値計算では使えない
処理の中でブロックするとダメなのでその判断も難しい

よって普通の言語では使うのが難しい

**デフォルトの名無しさん** · 2023/11/27(月) 01:36:12.87

>>706
使いたければc/c++にはむっかしからコルーチンにファイバーがあるから
native言語なんだからosの資源使う上で不利になるはずない

**デフォルトの名無しさん** · 2023/11/27(月) 01:38:37.07

>>706
＞Goの方が、CPUコアを効率的に使える

そう主張したかったら根拠を示さないとね
例えば逆の根拠として
Go各のgoroutineは別々の各々のスタック領域を必要とするけど
Rustはスタックレスなコルーチンだから必要とせずその分だけ効率的だね

**デフォルトの名無しさん** · 2023/11/27(月) 01:45:48.38

>>707
普通はスレッドプール使うやろ

**デフォルトの名無しさん** · 2023/11/27(月) 06:31:05.54

おれの作成したソフトは起動時に64個のスレッドを立ち上げているが常にサクサクだ

**デフォルトの名無しさん** · 2023/11/27(月) 07:50:36.80

>>712
言語は何？

**デフォルトの名無しさん** · 2023/11/27(月) 07:54:36.67

cppは光速

**デフォルトの名無しさん** · 2023/11/27(月) 09:19:45.20

>>701
それどころかプロセスを完全に終了させても解放されないリソースが残ることがある
OSを再起動してやっと治る
こんなもんOSのバグとしか言いようがない

**デフォルトの名無しさん** · 2023/11/27(月) 09:21:22.84

>>702
あるね
>>699 こそやったこと無い香具師だと感じる

**デフォルトの名無しさん** · 2023/11/27(月) 09:24:14.02

>>703
Windowsにforkがあれば良かったと思うことは何度かある

**デフォルトの名無しさん** · 2023/11/27(月) 09:26:12.71

ああでも
>>703
>一方windowsではexeなんでクソ重い上に扱いが面倒
>データ共有やプロセス間通信も一苦労だ
>だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う

ここは完全に間違ってるよ

**デフォルトの名無しさん** · 2023/11/27(月) 09:30:39.99

>>706
>C で、100スレッドを起動したら、
>CPU 使用率が高く、12秒も掛かったが、
>
>Goで100 goroutine を起動したら、
>6スレッドしか起動せず、9秒で済んだ

可笑しな理屈だな
スレッド数で比較するならgoでも100スレッド使って比較するか
Cの方でスレッド数増やさないCで描いたコルーチンで比較するべきだろ

**デフォルトの名無しさん** · 2023/11/27(月) 10:19:10.91

プロセスを分けて独立したメモリ空間の単位で障害を切り離して耐障害性を高めるのは昔からよく使われる方法だけどこれはスレッドやコルーチンでは代用できない

並行性を高める目的ならコルーチン+スレッドプールが最も効率が良い
C++やRustはまだまだ使いにくいけどGoやC#やSwiftのように使いやすいAPIが用意されれば誰もが当たり前のように使うようになる

**デフォルトの名無しさん** · 2023/11/27(月) 13:17:02.15

>>717
ある程度時間がかかる処理を並行で動かすという面でこれほど楽で使いやすいものはないしね
windowsへの移植性を上げるためにはforkを捨てなきゃならんのはかなり厳しい

**デフォルトの名無しさん** · 2023/11/27(月) 13:22:19.90

windowsくんェ
https://draftcode.github.io/2011/12/29/145918.html

**デフォルトの名無しさん** · 2023/11/27(月) 13:27:11.60

fork移植されてると思うけどそういう話ではなく？

**デフォルトの名無しさん** · 2023/11/27(月) 13:40:29.77

>>723
pythonじゃ使えないぞ

**デフォルトの名無しさん** · 2023/11/27(月) 14:04:14.09

遅くともcygwinとかで、なんちゃってforkは実装されてるけど、コレジャナイ感は付きまとうんだよな(個人の感想です

**デフォルトの名無しさん** · 2023/11/27(月) 14:10:54.29

execなしのforkなんて時代錯誤もいいところ
いまだに使ってるやついんのか？
さっさと引退するのが世のために

**デフォルトの名無しさん** · 2023/11/27(月) 14:17:35.21

RubyもNotImplementedError
Perlはエミュレーションしてるがすでに非推奨レベル

**デフォルトの名無しさん** · 2023/11/27(月) 14:21:41.56

こんどはforkを取り囲んでフェルマータするターンか

**デフォルトの名無しさん** · 2023/11/27(月) 15:12:24.83

forkは同じページを（書き換えるまで）共有できるのが売りだと思うけどwin版は最初からコピーするのか
そんな実装でfork爆弾作れるの？

**デフォルトの名無しさん** · 2023/11/27(月) 15:12:35.28

ま、雑談だからなおもしろければどうでもおっけー

**デフォルトの名無しさん** · 2023/11/27(月) 15:37:56.10

オジジジジジｗ

https://medaka.5ch.net/test/read.cgi/prog/1619943288/667
667: 仕様書無しさん 2023/11/24(金) 01:57:39.09
>>665
C++のスマポは機能が弱すぎてできないことが多すぎる
例えばヒープ領域しか指せないから
(L1キャッシュ効果と領域確保解放コスト無しで高速な)スタック領域の活用がスマポではできない

**デフォルトの名無しさん** · 2023/11/27(月) 15:50:29.33

スタック領域をスマートポインタで指す必要はあるの?

**デフォルトの名無しさん** · 2023/11/27(月) 15:57:04.75

先々で、うっかりfreeするような書き方してしまったときにコンパイルエラーで止まってほしい
実体としては生ポだけど、チェック用の何かにラップされてる…そういうスマポ

**デフォルトの名無しさん** · 2023/11/27(月) 17:16:07.46

いつものように誰かが書いてた受け売りで中身は理解してないんだろ
少し突っ込まれたら表面的なことを繰り返す壊れたレコードになる

**デフォルトの名無しさん** · 2023/11/27(月) 17:19:29.35

www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

**デフォルトの名無しさん** · 2023/11/27(月) 19:00:17.85

>>733
実装すれば良いのでは?

**デフォルトの名無しさん** · 2023/11/27(月) 19:12:23.49

>>731
スタック領域は勝手に解放されますが

**デフォルトの名無しさん** · 2023/11/27(月) 19:23:48.42

Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で効率的になってる話ではないか

**デフォルトの名無しさん** · 2023/11/27(月) 19:41:50.12

>>738
コードで示してよ
C++の

**デフォルトの名無しさん** · 2023/11/27(月) 19:55:41.13

>>738
単に「何でもスタックに積む」というだけでは？
ヒープはVec Box使わないと確保できないんじゃなかったっけ。

**デフォルトの名無しさん** · 2023/11/27(月) 19:57:13.46

C++は書くのがしんどい
Rustもしんどいけど、生成AIに書かせたコードもコンパイルとテスト通ればメモリリークの心配なく使えるので気持ちは楽

**デフォルトの名無しさん** · 2023/11/28(火) 03:07:58.34

Boxってヒープのメモリどうやって管理してんの？スコープ？

**デフォルトの名無しさん** · 2023/11/28(火) 06:19:45.83

>>734
ほんそれ
同じ香具師なんだろうバレバレ

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

>>742
unique ptrみたいな感じじゃない？

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

>>736
自分なりには考えてみてるんだけどね

ベーシックな車輪くらい、削り出せなきゃいけない
ダサいので試してるってのは他言はしないけどねここくらいだ

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

>>738
また嘘言ってる
Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で非効率的になってる

>>741
お前は死んだ方が良い

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

スタック使うってカーネルで使えるん？

**デフォルトの名無しさん** · 2023/11/28(火) 09:04:02.54

Rustの所有権チェックって、(コンパイル時にコストを寄せてるから)実行時はゼロコストじゃないん

へたくそに書いたら効率が下がる(たいてい実装効率が上がった犠牲)のは、C/C++も同じ

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

技術的選択というのは最終的には必ずトレードオフになるので
ある選択のプラス面だけしか見ない/考えない/認識できないやつは何やらせてもダメ

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

新人やお前らの前任の調子いいだけの奴がコンパイル通したコードで、rustとc++のどっちが安心できるかってことよ。

**デフォルトの名無しさん** · 2023/11/28(火) 12:37:00.84

c++に自動変数専用参照とかあるといいんだけどなぁ。
自動変数にあるスマートポインタは参照渡ししたい。

**デフォルトの名無しさん** · 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); //次のスタックフレームに渡すのも合法
}