結局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/24(金) 07:39:29.33

>>652
要素の型が実体とポインタ両方に対してうまく動くようにする

それはポインタを部分特殊化しろ、ということでは？

**デフォルトの名無しさん** · 2023/11/24(金) 08:38:00.98

>>663
同意を求めるなよw
お前の用途ではSTLで十分ってだけ
そうじゃない場合もある
STLで足りるならboostもEASTLも存在してない

**デフォルトの名無しさん** · 2023/11/24(金) 11:26:41.73

>>666
>>652
>テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
>まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
これがいったい何のことを言っているのか分からんので
STLで問題を指摘させれば共通の題材として議論できるからSLT取り上げた

**デフォルトの名無しさん** · 2023/11/24(金) 11:31:35.71

継承を使いこなせない者同士仲良くしろよなw

**デフォルトの名無しさん** · 2023/11/24(金) 14:20:00.82

嫌儲にまでスレ立てることないだろｗ

**デフォルトの名無しさん** · 2023/11/24(金) 14:23:40.25

全然伸びてなくて草
こんな過疎スレで敗走したからって嫌儲民おらに力を分けてくれーーってやろうとしたけど
そこでも無視されてる
情けない奴だ
だからゴミクズなんだよ

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

Why I think C++ is still a desirable coding platform compared to Rust
https://lucisqr.substack.com/p/why-i-think-c-is-still-a-very-attractive

**デフォルトの名無しさん** · 2023/11/24(金) 14:36:54.58

>>671
そもそも前半の話いる？w
的外れ過ぎて意味のない指摘だよ

**デフォルトの名無しさん** · 2023/11/24(金) 16:11:19.50

>>671
これは酷いw

**デフォルトの名無しさん** · 2023/11/24(金) 16:25:00.95

いくらめんどくさくても安全のお守りがほしいんすわ
C++製システムがクラッシュしてうなだれたあの日の鬱憤が安全を求めるんすわ

**デフォルトの名無しさん** · 2023/11/24(金) 16:34:40.23

>>671
何故この手のやからって、
自分は今まで大丈夫だったから他の人(今度の新卒社員とか)も大丈夫に違いないと思えるんだろうか。
いつも一人で仕事してるのかな。

**デフォルトの名無しさん** · 2023/11/24(金) 16:45:30.90

>>671
その人はRustを知らなすぎるな
C++はインラインアセンブリがある云々もRustにもあるし
算術ラッピング演算の件もRustはラッピングの有無両方が用意されてるのを知らずに書いていたり

**デフォルトの名無しさん** · 2023/11/24(金) 16:52:45.75

フルボッコで草

**デフォルトの名無しさん** · 2023/11/24(金) 16:55:26.04

めっちゃ感想来てるｗ

俺は読まずに貼った、おもしろそうだったから
[Roast Me] って付いてたので、異論は認める系の日記かなって思ってた
仕事終わったら俺も読む気にしないから感想はご自由に

**デフォルトの名無しさん** · 2023/11/24(金) 19:51:30.59

>>674
わかる。他人の書いたC++ライブラリがめっちゃメモリリークする時とかそう思うわ

**デフォルトの名無しさん** · 2023/11/24(金) 19:53:16.58

元記事に英語でコメント付けに行くことはしい内弁慶たちであった

**デフォルトの名無しさん** · 2023/11/24(金) 20:53:52.01

>>652
要約: バカには無理

**デフォルトの名無しさん** · 2023/11/24(金) 22:58:47.93

使うなと言ってもバカはクラス継承をどうしても使いたがって質を下げるため
モダンなプログラミング言語は一斉にクラスごと言語から排除した

**デフォルトの名無しさん** · 2023/11/24(金) 23:09:27.03

そうそうバカはclassやextendを無くせば実装継承が無くなったと勘違いするからバカに気づかれないようにカモフラージュして実装してバカが無節操に使わないようにしてるんだよなぁ

**デフォルトの名無しさん** · 2023/11/24(金) 23:40:23.66

そうしてマイナー言語マニアの思い出の一つとして
長く記憶に留まる言語となるであろう

**デフォルトの名無しさん** · 2023/11/25(土) 00:57:31.51

>>683
実装継承の定義教えてくれ

**デフォルトの名無しさん** · 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の悪いとこ透けて見えたわ