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

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/16(木) 17:15:50.99

C++は次々と新たな機能を増やし続けてきたが増築工事だから色んな点で限界が多い
例えば話が出ている広い意味のnull安全はC++がoptionalの導入をとっくに行っているが
・なかなか普及しない
・既存ライブラリの仕様とのチグハグ
・パターンマッチング機能の導入がまだなので使い勝手が悪い
などの問題が山積みであまり使われていない
C++の他の機能導入でも似たような状況が多い
Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
C++をさっさと棄てるのが現実解であると理解できた

**デフォルトの名無しさん** · 2023/03/16(木) 17:23:01.97

C++はなんでも書けるかわりに、いまや考えなしに勝手に組み合わせるとめちゃくちゃになるんだよね
Rustには引き算の美学の成果が入ってる
C++も、先頭で縛りを宣言できるようにして、美しく書けるようになるべきだ絶対に

**デフォルトの名無しさん** · 2023/03/16(木) 17:47:47.57

ソースコードのコンパイル・ビルドの時点ですべての問題点をエラーで全部弾いてくれたら理想的だね
大抵はテストツールまで書かないと使えない

**デフォルトの名無しさん** · 2023/03/16(木) 19:59:01.19

>>350
コンストラクタでlockしてデストラクタでunlockするproxyクラス作って
その一時オブジェクト経由で触れば良いだけなので何を今更という感じ
メモリ安全は別にデバッガですぐ特定できるし
マルチスレッドではRustの利点がない
デッドロックが検出できたらまぁ嬉しいが?

**デフォルトの名無しさん** · 2023/03/16(木) 20:03:11.00

クラス笑

**デフォルトの名無しさん** · 2023/03/16(木) 20:03:55.24

>>354
多くの人に使ってもらおうと思ったらCで書いて
各言語のラッパーを提供するってのが多い
RustにこのCの代わりができれば良いんだけども?
もしRustユーザしかリンクできないライブラリだったら
Rustはそもそもユーザー数が少ないし
Rustで書く動機が減る

**デフォルトの名無しさん** · 2023/03/16(木) 20:07:00.05

>>357
多人数でやるプロジェクトにはC++は自由過ぎて
その点は書き方にある程度拘束される意義はあると思う

**デフォルトの名無しさん** · 2023/03/16(木) 23:56:33.56

>>320
ありがと
意外と変わらないんだ

**デフォルトの名無しさん** · 2023/03/17(金) 00:02:12.50

Rustでゲームエンジンやグラフィックソフト作れたら認めてやるよ

**デフォルトの名無しさん** · 2023/03/17(金) 00:04:03.80

DTMに使いそうなDAWソフトとかでもいいぞ
書き方はGitHubにいろんなOSSの見本があるから簡単でしょ？

**デフォルトの名無しさん** · 2023/03/17(金) 00:04:27.28

Rust使いこなせるくらいなら余裕のはず

**デフォルトの名無しさん** · 2023/03/17(金) 00:14:30.94

SDLのRustバインディングはあるけども
Rustで本体を書いて他の言語のバインディングって出来るの?
他の言語との乖離でRustならではの部分が封じられて
あんまり嬉しくないような気もするのだが?
それともRustでライブラリ書いたらターゲットはRustだけになるのかな?

**デフォルトの名無しさん** · 2023/03/17(金) 00:14:49.50

>>356
>Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
俺とは感覚が違う。Rustを美しく感じない。

**デフォルトの名無しさん** · 2023/03/17(金) 00:21:48.75

これは理解できるし、はっきりそう書けばよい:
・Rustの本を書きました。Rustは良い言語なので本を買ってください。
・Rust用のライブラリを書きました。Rustは良い言語なのでライブラリを買ってください。
これは理解できないし、問題:
・C++は害悪なのでRustをみんなが使って世の中を良くしよう。
・自分がC++を使いこなせないのに、使いこなせる人が許せないから、使いこなせるRustを普及させたい。

**デフォルトの名無しさん** · 2023/03/17(金) 00:39:18.46

RustはC++なんかよりずっと簡単! <- これならわかる

**デフォルトの名無しさん** · 2023/03/17(金) 00:51:57.03

>>370
それも意見が分かれそうだ。

**デフォルトの名無しさん** · 2023/03/17(金) 00:54:59.09

>>367
出力をcdylibにすれば一般的なCソースのライブラリと同じ形式（soとかdll）で出力されるはず
当然FFI絡みの制約は出てくるしextern指定とかも必要だけど境界部分だけ気を付ければ内部は自由にRustできる

wgpuはRustで書かれたグラフィックライブラリだけどその機能をC/C++から呼ぶためのwrapperでwgpu-nativeがあって
さらにそのC用のwrapper経由で別言語（Pythonとか）のwrapperが作られてたりする
依存関係がややこしいけど
wgpu (Rust製、Rust用Lib出力) ← wgpu-native (Rust製、C用Lib出力） ← wgpu-py (C+Python製、Python用ライブラリ）
みたいな構造

**デフォルトの名無しさん** · 2023/03/17(金) 01:04:51.03

>>372
なるほどー

**デフォルトの名無しさん** · 2023/03/17(金) 05:58:07.48

>>359
Rustならマルチスレッドでもマルチタスク(=グリーンスレッド)でも書きやすく
さらにデータ競合を完全に防げるRustしか現状の言語では選択肢ないと思うよ
各言語で書き比べてみれば一目瞭然
そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる

**デフォルトの名無しさん** · 2023/03/17(金) 10:42:47.45

>>374
>>そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
全く進んでいないのだが?w
俺の周りではC++やJavaでマルチスレッドで書く奴の方が多い
というかそもそもRustを使っている奴は一人もいないw
妄想なのか詐欺師なのか...
LinuxでもさもRustの導入が進んでるように言うが実際は>>39だし...

**デフォルトの名無しさん** · 2023/03/17(金) 10:55:37.94

マルチスレッドはまあ普通だけどマルチタスクはめちゃくちゃ書きにくいぞ
単純なWeb Serverくらいならいいがちょっと凝った処理を書こうとするとくっそ面倒くさい
tokio依存なのもダメなところ

**デフォルトの名無しさん** · 2023/03/17(金) 11:06:44.98

そここそ、OSがRust化するっていうんだから、きれいなAPIが出てきてほしいね
結局、効率を求めたらC API に肉薄することになるし

**デフォルトの名無しさん** · 2023/03/17(金) 11:15:24.56

Linuxの現状はRustでドライバが書けるようになったってだけだよ
誤解なきよう

**デフォルトの名無しさん** · 2023/03/17(金) 11:17:48.64

>>376
マルチタスク(並行)で綺麗に書ける言語はRustとGoだけだな
GoはPromise(Future)使わないあのスタイルに寄せられるのとGC言語であるため
Rustが汎用では筆頭言語になる

**デフォルトの名無しさん** · 2023/03/17(金) 11:33:47.61

>>376
だよな
Rustの非同期が簡単だと勘違いしてるやつはチュートリアルレベルしかやったことないやつだと思うわ

**デフォルトの名無しさん** · 2023/03/17(金) 11:43:37.53

>>380
自分でpollしたりするのも含めて色んなレベルで書いているが簡単だぞ
Rustで並行並列が難しいと言うならばとこが難しいのかを具体的に述べよ
そしてそのケースでRustの代わりに使える別言語があるならば述べよ

**デフォルトの名無しさん** · 2023/03/17(金) 11:51:53.17

Goと比較したら性能面でも劣ることが多くて同程度の性能を実現したければ手動であれこれやらないといけないからな

**デフォルトの名無しさん** · 2023/03/17(金) 12:19:57.65

>>381
そうやって自分が分かってない事を無料で聞き出してしまおうとする。ずる賢い。

**デフォルトの名無しさん** · 2023/03/17(金) 12:31:22.55

>>382
Goが速い遅いと言ってたのは昔の話
今はGoもRust tokioも改善してほぼ同じwork stealing方式になり似たりよったりの速度
C++をあきらめてRustに対抗できるGoを持ち出すしかないほど追い込まれてるのかね

>>383
Rustで並行並列が他の言語より難しいことはない
難しいと主張するならば何が難しいのかを述べたまえ
もし本当に具体的に困ったことがあるならばアドバイスできる

**デフォルトの名無しさん** · 2023/03/17(金) 12:38:18.49

追い込まれてるってなんだろうね
楽しそうだね

**デフォルトの名無しさん** · 2023/03/17(金) 12:39:30.67

この人は妄想癖がある

**デフォルトの名無しさん** · 2023/03/17(金) 12:56:40.90

>>384
>Rustで並行並列が他の言語より難しいことはない
>難しいと主張するならば何が難しいのかを述べたまえ
>もし本当に具体的に困ったことがあるならばアドバイスできる
問題意識があること、気付くこと、それが大事。
あなたにはそれがない。

**デフォルトの名無しさん** · 2023/03/17(金) 13:03:24.97

>>383
わかり味
こいついつも教えて君だよなぁ

総論しか書けないところみると
マニュアルだけ読み込んだペーパープログラマーがそれを隠すためのネタを欲してるようにしか見えない

**デフォルトの名無しさん** · 2023/03/17(金) 13:03:47.55

Goはgoroutine間のデータ競合の発見を実行時のランタイムでやるしかなく
Goはあまりお勧めできないなあ
メモリ共有せずチャネルを使う範囲ならGoでもいいけど
Rustでもチャネルはもちろん使えるし
共有メモリで安全にデータ競合を起こさず使えるからRustがいいよ

**デフォルトの名無しさん** · 2023/03/17(金) 14:28:10.79

ほんと嘘ばっかりだな

**デフォルトの名無しさん** · 2023/03/17(金) 15:04:18.42

>>389
Goに限らずデータ競合を実行時にしか検出できない言語ではデータ競合が時々しか起きない場合のデバッグが難しい
Rustを使うべき理由はデータ競合を静的に検出できる点にある

**デフォルトの名無しさん** · 2023/03/17(金) 15:55:42.60

>>391
それはマルチスレッドプログラミングのアルゴリズムをRustは強く制限しているから。
だから、その制限から外れるようなアルゴリズムは使えないので柔軟性は欠く。

**デフォルトの名無しさん** · 2023/03/17(金) 16:03:41.59

そこが、新規書き起こしのRustのメリットでもあるわけよな

**デフォルトの名無しさん** · 2023/03/17(金) 16:05:57.04

>>393
そして、独自のアルゴリズムは使えないので、アルゴリズムの研究には向かない。

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

第n次LinkedListおじさんvsGCおじさん戦争

**デフォルトの名無しさん** · 2023/03/17(金) 16:16:19.10

頑張ったら書けるんじゃねーの、それもsafeで
そのへんはC++もおなじ自分も、ニッチすぎる薄いラッパなら頑張って書くし

**デフォルトの名無しさん** · 2023/03/17(金) 16:20:04.75

>>392
Rustで記述できないマルチスレッドプログラミングのアルゴリズムなんてものは存在しない
Rustは柔軟性が非常に高い

**デフォルトの名無しさん** · 2023/03/17(金) 16:32:10.93

>>397
嘘を書かないで。

**デフォルトの名無しさん** · 2023/03/17(金) 16:41:56.97

Rustで書けないのがあると主張している人が例を出せばいいんじゃね
Rustにそんな制限はないからすべて書けるよたぶん

**デフォルトの名無しさん** · 2023/03/17(金) 16:52:07.05

結局何年か後にはlinux kernelを全部rustで書くつもりなんかな

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

書けなくはないだろ、書きやすいかどうかだ実際どうなん
C++は、なんでも書けるが、油断すると複雑すぎる代物ができあがる
そんで、「でも例外がくるとー」「でも異常値がくるとー」って

**デフォルトの名無しさん** · 2023/03/17(金) 17:01:41.44

>>399
マルチスレッドのアルゴリズムは非常に多く存在していて、ある意味では無限に
考えられる。Rustは数個しかサポートしていないから、無理。

**デフォルトの名無しさん** · 2023/03/17(金) 17:26:21.78

>>402
Rustで書けない例があると主張したいなら例を出せばいいんじゃね
Rustに何か制限があるわけじゃないからおそらくなんでも書けるよ

**デフォルトの名無しさん** · 2023/03/17(金) 17:31:51.55

>>403
unsafeになる。

**デフォルトの名無しさん** · 2023/03/17(金) 17:42:50.37

>>404
マジ？信じられん
もし本当ならそのunsafeを使わざるを得なかった例を具体的に出せばいいんじゃね

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

unsafeをゼロにするよりも、極小なunsafeブロックを組み込んで華麗にキメてほしいね
これはC++も同様

**デフォルトの名無しさん** · 2023/03/17(金) 17:52:35.17

>>400
そういう枯れた古いものをわざわざ書き直すことに熱意を燃やせる人間は少ない
新世代のデータベースやcrypt/blockchainのように金になる新しい成長分野ではc/c++よりもrustがよく使われてる

技術の自然な世代交代は既存システムの置き換えから始まるものではない

**デフォルトの名無しさん** · 2023/03/17(金) 18:01:30.86

>>405
次のことが成り立っていれば教えてもらわなくても自然に分かる:
・マルチスレッドの事を理解している。
・Rustのことを理解している。
・算数的直観力に優れる。

**デフォルトの名無しさん** · 2023/03/17(金) 18:03:48.04

複製おじさん vs 100点おじさん
Fight!

**デフォルトの名無しさん** · 2023/03/17(金) 18:24:08.50

>>401
そのへんの問題もRustだと安全安心なのがいいよなー
特に例外機構を無くしたのは大成功
あとResult放置してると警告もしてくれるしな

>>404
そのunsafe使わないと書けなかったコードを出してみ
寄ってたかって添削してやろう

**デフォルトの名無しさん** · 2023/03/17(金) 18:36:02.65

>>410
俺は天才だから、お前みたいな凡人に無料でヒントをくれてやらない。

**デフォルトの名無しさん** · 2023/03/17(金) 19:13:16.48

Rustって、削ぎ落したものは復活させません、って宣言とかしてるん?

**デフォルトの名無しさん** · 2023/03/17(金) 19:55:25.86

>>408
Rustをあんまり知らんけど言語間に根本的な差はなくね？

**デフォルトの名無しさん** · 2023/03/17(金) 20:02:50.35

>>408はいつものキチガイ
RustもC++もコードを書けたことがない
相手にするだけ無駄

**デフォルトの名無しさん** · 2023/03/17(金) 20:19:10.88

>>414
今さらなに言ってるんだ？
ここにはキチガイしかいないぞ？
俺もお前もな

**デフォルトの名無しさん** · 2023/03/17(金) 20:29:34.70

>>413
ん？だから何？

**デフォルトの名無しさん** · 2023/03/17(金) 21:29:42.97

>>416
アルゴリズムを書ける書けないの差はでない

**デフォルトの名無しさん** · 2023/03/17(金) 23:44:57.66

Rustほとんど知らん俺でも総合的にRustのほうがC++よりはいいだろと思う
C++より後発言語で、で、ライバルになるC＋＋に劣っているようじゃダメだからな
で、お前らは、すごいRustで具体的に何を作っているんだ？

**デフォルトの名無しさん** · 2023/03/18(土) 00:11:15.51

ChatGPT先生に聞いてみた
>>404の言う通り

template <typename T>
class LockFreeStack {
public:
void push(const T& value) {
Node* new_node = new Node(value);
new_node->next = head.load(std::memory_order_relaxed);
while (!head.compare_exchange_weak(new_node->next, new_node,
std::memory_order_release,
std::memory_order_relaxed));
}
std::shared_ptr<T> pop() {
Node* old_head = head.load(std::memory_order_relaxed);
while (old_head && !head.compare_exchange_weak(old_head, old_head->next,
std::memory_order_acquire,
std::memory_order_relaxed));
return old_head ? std::make_shared<T>(old_head->value) : nullptr;
}
private:
struct Node {
T value;
Node* next;
Node(const T& value) : value(value), next(nullptr) {}
};
std::atomic<Node*> head{nullptr};
};

**デフォルトの名無しさん** · 2023/03/18(土) 00:31:48.86

先生にからかわれとるぞｗ

**デフォルトの名無しさん** · 2023/03/18(土) 00:53:02.93

>>419はこれと同じのをRustで書いたらunsafeになる(だろ?)
って言いたいんだろ
偉大なるChatGPT先生が言うんだから間違いないだろな

**デフォルトの名無しさん** · 2023/03/18(土) 00:58:57.68

>>421
いやChatGPTは信用しない方が良い
俺はRustは良く分からんがChatGPT曰く
>Rustには、このようなロックフリーなデータ構造を提供する
>クレート（ライブラリ）が存在します。その一つがcrossbeamです。
>このクレートは、スレッドセーフで効率的なデータ構造を提供しており、
>crossbeam内でUnsafeな操作が行われているにもかかわらず、
>APIを通じて安全に使用できます。
だそうな
crossbeamってRustで書かれとらんのかな?

**デフォルトの名無しさん** · 2023/03/18(土) 01:14:24.86

>>422
本当は、ライブラリの中だけをunsafeにして、アプリ側はsafeに出来るケースも有れば、
アプリ側も unsafe を消せないケースもありえる。

**デフォルトの名無しさん** · 2023/03/18(土) 01:17:39.13

unsafeってキーワード使えばチェックをオフにできるのね

**デフォルトの名無しさん** · 2023/03/18(土) 01:29:02.55

>>420
Rustで書いてみよう！

**デフォルトの名無しさん** · 2023/03/18(土) 04:35:18.48

ArcとAtomicでほぼそのまま書けるけど
pointer dereferenceのためにunsafeは必須

**デフォルトの名無しさん** · 2023/03/18(土) 10:03:55.24

言語マウントごっこにしか使われてないrust

**デフォルトの名無しさん** · 2023/03/18(土) 10:25:46.77

no chance

**デフォルトの名無しさん** · 2023/03/18(土) 11:41:47.24

平日の昼にID真っ赤なのは仕事か
板違いのスレで必死に毎日お疲れさん

**デフォルトの名無しさん** · 2023/03/18(土) 14:02:46.54

ちょうどオライリーから「Rust Atomics and Locks」という本が出てるよ

基本的な内容を説明してる本なのでC++でatomicsやmemory orderingに慣れ親しんでる人がわざわざ買うほどのものではないかもしれないけど
かなりわかりやすくまとまってるのでRustでこの辺りの機能を使ったコードを良く書く人は読んで置いて損はないと思う

**デフォルトの名無しさん** · 2023/03/18(土) 16:09:57.63

ほう
https://bokuweb.github.io/undefined/articles/20230205.html

**デフォルトの名無しさん** · 2023/03/18(土) 18:42:10.12

Lock-Freeなデータ構造を自分で作りたい人はこれを見るといい

Porting Java's ConcurrentHashMap to Rust (part 1)
https://www.youtube.com/watch?v=yQFWmGaFBjk

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

> cargo new hoge
> cargo run
→ 3MB
main.rs に
use clap::Parser;
追加すると
> cargo run
→ 100MB 超えるんだが
どうすれば容量減らせるん？

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

とりあえず--releaseつける

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

しらんけど
https://igaguri.はてなぶろぐ.com/entry/2020/06/07/133847
https://crates.io/crates/cargo-clean-recursive

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

とりあえずは
cargo clean
で良いはず
最初から余計なのは造りたくないって言う話ならほんまにしらん

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

>>436
ありがとうございました

**デフォルトの名無しさん** · 2023/03/20(月) 08:59:55.73

やっぱC++にもボローチェッカ欲しい
なんならCにも欲しい
attributeとか併用したら、やってできないことはないんじゃねーの

**デフォルトの名無しさん** · 2023/03/21(火) 17:20:17.93

rg3d はなぜ
https://github.com/rg3dengine/rg3d
から
https://github.com/FyroxEngine/Fyrox
に改名したのですか？

**デフォルトの名無しさん** · 2023/03/21(火) 17:50:34.39

rustの読み物公式が面白いのしっかり出してるから
それ読むだけでも大分良い
後発言語らしくイイトコどりしまくってる
null無くした代わりになんでもかんでもラップしてるから若干だるいけど
すげー面白い

**デフォルトの名無しさん** · 2023/03/21(火) 19:41:09.03

Unity超えるゲームエンジン作ってから言え

**デフォルトの名無しさん** · 2023/03/21(火) 19:42:14.14

Blenderとかでもいいよ

**デフォルトの名無しさん** · 2023/03/21(火) 21:54:25.24

cpp2rsみたいのがじきできるから、そしたら一発
ただ、それだと、safeではあるけど、Rustのシンプルさは(メリットとして)失うな

**デフォルトの名無しさん** · 2023/03/22(水) 07:30:44.03

>>443
ほんとにできる？

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

文法がRustなだけで
Rustのコードとして使い物にならん
ゲテモノが出て来るわ
今のGPTも酷い

**デフォルトの名無しさん** · 2023/03/22(水) 09:47:28.48

ああ、あと全自動とは言わないあっちこっちで、あれなおせーこれなおせーって言われるかと

**デフォルトの名無しさん** · 2023/03/22(水) 10:40:01.19

たしかに、C++でメモリ安全性を静的チェックするツールを作るのはなかなか難しいもんかね？

**デフォルトの名無しさん** · 2023/03/22(水) 12:19:59.74

gccだとvargrindとかあるけどね

**デフォルトの名無しさん** · 2023/03/22(水) 14:27:48.09

valgrindはgcc関係なくないか？
rustでもメモリリークの確認に使う

有用なツールだけど静的チェックと呼べるのかは疑問

**デフォルトの名無しさん** · 2023/03/22(水) 21:31:28.83

valgrindは実行時チェックだから出現レアケースだと時間内に検出できない

**デフォルトの名無しさん** · 2023/03/22(水) 21:43:05.82

AddressSanitizerでもValgrindでもmtraceでも好きなの選べ
https://kivantium.hateblo.jp/entry/2018/07/14/233027

**デフォルトの名無しさん** · 2023/03/22(水) 21:46:10.74

全て実行時チェックだな

**デフォルトの名無しさん** · 2023/03/22(水) 21:54:30.07

静的ツールだとこんなのもあるね
https://cppcheck.sourceforge.io/

スマートポインタ使えばそもそもいらんがね

**デフォルトの名無しさん** · 2023/03/23(木) 11:01:43.91

C++で出来る人には要らん

**デフォルトの名無しさん** · 2023/03/23(木) 11:35:46.79

メモリ不安全の何が悪いかってメモリリークじゃなくて間違った場所にアクセスしちゃうことだと思うのだが