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

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/08(月) 12:31:11.67

>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:44.96

>>201
これは良いサンプル
https://www.youtube.com/watch?v=U-_43dmdV_I

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:46.40

>>249
内部で呼ばれるcargo packageの仕様っぽいね
https://doc.rust-lang.org/cargo/commands/cargo-package.html
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな

**デフォルトの名無しさん** · 2023/05/08(月) 12:48:52.30

>>228
全ての素数の積でπを造る公式あるな

**デフォルトの名無しさん** · 2023/05/08(月) 12:50:45.02

>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き

**デフォルトの名無しさん** · 2023/05/08(月) 12:56:17.27

Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？

**デフォルトの名無しさん** · 2023/05/08(月) 12:57:11.50

thx!

**デフォルトの名無しさん** · 2023/05/08(月) 13:48:29.03

今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。

**デフォルトの名無しさん** · 2023/05/08(月) 14:22:47.81

>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね

**デフォルトの名無しさん** · 2023/05/08(月) 15:04:56.15

>>245
AIにRustのコード吐かせる理由なんて無いよね

**デフォルトの名無しさん** · 2023/05/08(月) 15:39:48.45

Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので

**デフォルトの名無しさん** · 2023/05/08(月) 15:42:47.04

速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。

**デフォルトの名無しさん** · 2023/05/08(月) 16:19:16.98

>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな

**デフォルトの名無しさん** · 2023/05/08(月) 16:35:56.27

>>263
llvmの方がgccより性能良くなった?

**デフォルトの名無しさん** · 2023/05/08(月) 16:41:27.47

>>265
12年前から既にclangの方が速いです:
https://stackoverflow.com/questions/3187414/clang-vs-gcc-which-produces-faster-binaries

**デフォルトの名無しさん** · 2023/05/08(月) 17:24:13.85

>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し

機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい

**デフォルトの名無しさん** · 2023/05/08(月) 18:43:10.50

>>266
その手の話は信用ならねえな

**デフォルトの名無しさん** · 2023/05/08(月) 20:09:42.31

>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？

**デフォルトの名無しさん** · 2023/05/08(月) 22:23:28.00

>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない

ちなウォーターフォールね

**デフォルトの名無しさん** · 2023/05/08(月) 22:48:34.95

そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない

**デフォルトの名無しさん** · 2023/05/09(火) 02:35:37.18

公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ

**デフォルトの名無しさん** · 2023/05/09(火) 02:55:17.89

yank

**デフォルトの名無しさん** · 2023/05/09(火) 03:40:24.06

>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。

**デフォルトの名無しさん** · 2023/05/09(火) 06:12:08.21

そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな

**デフォルトの名無しさん** · 2023/05/09(火) 07:51:20.97

yankしても消えないやん？

**デフォルトの名無しさん** · 2023/05/09(火) 08:28:08.83

いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ

**デフォルトの名無しさん** · 2023/05/09(火) 09:22:12.89

プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ

**デフォルトの名無しさん** · 2023/05/09(火) 10:03:50.18

vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち

**デフォルトの名無しさん** · 2023/05/09(火) 10:17:59.79

とフィボナッチイテレータより高度なプログラムが書けない人が申しております

**デフォルトの名無しさん** · 2023/05/09(火) 10:29:01.80

>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ

**デフォルトの名無しさん** · 2023/05/09(火) 11:12:55.99

>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt

>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt

>まあClone回避パターンもありRustは完璧だ
doubt

よくこんな短文で嘘ばかりかけるな

**デフォルトの名無しさん** · 2023/05/09(火) 11:27:29.07

複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい

**デフォルトの名無しさん** · 2023/05/09(火) 11:41:48.76

オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん

**デフォルトの名無しさん** · 2023/05/09(火) 12:08:20.62

オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ

**デフォルトの名無しさん** · 2023/05/09(火) 12:19:41.76

な、単発だろ

**デフォルトの名無しさん** · 2023/05/09(火) 12:27:45.30

プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい

**デフォルトの名無しさん** · 2023/05/09(火) 13:50:33.38

>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。

**デフォルトの名無しさん** · 2023/05/09(火) 14:18:30.40

>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利

**デフォルトの名無しさん** · 2023/05/09(火) 14:27:49.18

>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。

**デフォルトの名無しさん** · 2023/05/09(火) 14:49:54.81

>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る

**デフォルトの名無しさん** · 2023/05/09(火) 15:08:56.17

https://stackoverflow.com/questions/57259126/why-does-the-rust-compiler-not-optimize-code-assuming-that-two-mutable-reference

だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます

**デフォルトの名無しさん** · 2023/05/09(火) 15:10:24.05

>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。

**デフォルトの名無しさん** · 2023/05/09(火) 15:21:42.16

>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね

**デフォルトの名無しさん** · 2023/05/09(火) 16:23:47.59

重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです

**デフォルトの名無しさん** · 2023/05/09(火) 16:57:31.86

>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる

Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い

**デフォルトの名無しさん** · 2023/05/09(火) 17:04:50.38

コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな

**デフォルトの名無しさん** · 2023/05/09(火) 17:08:17.41

>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする

**デフォルトの名無しさん** · 2023/05/09(火) 17:09:31.38

そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です

**デフォルトの名無しさん** · 2023/05/09(火) 17:30:52.58

Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど

**デフォルトの名無しさん** · 2023/05/09(火) 17:33:18.67

おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな

**デフォルトの名無しさん** · 2023/05/09(火) 17:35:11.58

普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ

**デフォルトの名無しさん** · 2023/05/09(火) 17:49:39.63

速度じゃないわな
実行時間だ
速度だと
c > c++ > rust

**デフォルトの名無しさん** · 2023/05/09(火) 21:13:21.70

>>300
Rustは適当に書いたらコンパイル通らない。

**デフォルトの名無しさん** · 2023/05/09(火) 21:36:53.43

いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？

**デフォルトの名無しさん** · 2023/05/09(火) 21:55:51.60

>>305
できるよw

**デフォルトの名無しさん** · 2023/05/09(火) 22:07:22.50

>>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね

**デフォルトの名無しさん** · 2023/05/09(火) 22:10:15.60

なるほどね
俺の全力のC++コードじゃRustには敵わないようだ

**デフォルトの名無しさん** · 2023/05/09(火) 23:53:36.96

>>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている

**デフォルトの名無しさん** · 2023/05/10(水) 07:24:49.96

テキトーに書いてもコンパイルが通る言語に憧れるなあ

**デフォルトの名無しさん** · 2023/05/10(水) 08:38:28.50

体感ではこうかな
c > rust > c++

**デフォルトの名無しさん** · 2023/05/10(水) 08:59:49.54

複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ

当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい成果も目に見えると思うたぶんCでは力不足だしね

**デフォルトの名無しさん** · 2023/05/10(水) 10:30:02.81

>>308
全力のrustコードを書けばいい

**デフォルトの名無しさん** · 2023/05/10(水) 12:47:47.75

C++相談室part161、ﾜｯﾁｮｲ導入直前のスレ
https://mevius.5ch.net/test/read.cgi/tech/1653135809/343-381
https://mevius.5ch.net/test/read.cgi/tech/1653135809/481-650

C++相談室part162、ﾜｯﾁｮｲ導入直後
https://mevius.5ch.net/test/read.cgi/tech/1667194175/
"Rust" の検索結果: 1件

は～

**デフォルトの名無しさん** · 2023/05/10(水) 12:48:26.46

lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。

**デフォルトの名無しさん** · 2023/05/10(水) 12:49:05.61

Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい

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

>>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語

>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん

**デフォルトの名無しさん** · 2023/05/10(水) 13:15:44.86

crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん

**デフォルトの名無しさん** · 2023/05/10(水) 14:03:23.86

lintにmissing_docs
https://doc.rust-lang.org/rustdoc/lints.html#missing_docs
があるけどデフォルトでallowになってるらしい

lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs

**デフォルトの名無しさん** · 2023/05/10(水) 14:21:07.26

>>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和

**デフォルトの名無しさん** · 2023/05/10(水) 16:48:54.33

>>319
㌧クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる

**デフォルトの名無しさん** · 2023/05/10(水) 17:11:01.06

>>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！

**デフォルトの名無しさん** · 2023/05/10(水) 17:13:13.74

コメントカバー率の計算対象は限定されてるよ
https://doc.rust-lang.org/rustdoc/unstable-features.html#--show-coverage-calculate-the-percentage-of-items-with-documentation

**デフォルトの名無しさん** · 2023/05/11(木) 03:47:03.48

C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね

**デフォルトの名無しさん** · 2023/05/11(木) 08:01:31.45

https://twitter.com/markrussinovich/status/1656416376125538304

If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel!
https://pbs.twimg.com/media/FvzF4ZraQAUumaq.png
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2023/05/11(木) 11:43:59.84

win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys

**デフォルトの名無しさん** · 2023/05/11(木) 12:35:35.38

ttps://japan.zdnet.com/article/35198420/

**デフォルトの名無しさん** · 2023/05/11(木) 12:57:22.38

>>327
C++は何故か年々人気が上がってるね

**デフォルトの名無しさん** · 2023/05/11(木) 13:16:26.32

C++0xの暗黒時代を知らない世代が増えたんだろう

**デフォルトの名無しさん** · 2023/05/11(木) 14:21:03.16

>>317
上澄みだけ使うならライブラリも豊富だし悪くない。

本来なら、c++標準化団体がAccelerated C++みたいなのを用意してメンテナンスすべきだと思うけどなぁ。

**デフォルトの名無しさん** · 2023/05/11(木) 14:44:20.03

いらね

**デフォルトの名無しさん** · 2023/05/11(木) 15:04:29.85

デザパタ流行した時ほにゃららパターンのほとんどが理解できなかったけどそのうち理解しなくても何の問題もない事が判った
うんこうんこうんこー

**デフォルトの名無しさん** · 2023/05/11(木) 15:26:04.23

>>332
実務で今使ってるのは、state, proxy, singleton, factoryくらいかな。
あとは使ってないね。

**デフォルトの名無しさん** · 2023/05/11(木) 16:10:38.63

近年の C + 人気は上の画像でも見ただろ
競技プログラミングだよ

**デフォルトの名無しさん** · 2023/05/11(木) 16:14:51.13

GoFのパターンはiteratorとかadapterも含めてるから多分無意識で使ってるよ
昔のforループはi++で回すのが普通だったし
JavaにIterator（foreach構文）が追加されたのが1.5くらいのはず

**デフォルトの名無しさん** · 2023/05/11(木) 18:30:22.74

懐かしの　何とかの呼吸　○の型　ほにゃらら！が沢山あるけど
使わないときは使わないと言うだけです

**デフォルトの名無しさん** · 2023/05/11(木) 18:41:36.44

Rustの呼吸　一の型　mut代入！
Rustの呼吸　二の型　シャドーイング！

**デフォルトの名無しさん** · 2023/05/11(木) 18:56:15.63

それ現行コンテンツちゃうの? (初クール初回から録画だけして観てない

**デフォルトの名無しさん** · 2023/05/11(木) 19:34:36.36

C++コアガイドラインに従い、IDE組み込みのチェッカーを使う
これが一般的なスタイル
これだけであなたの悩みはすべて解決する

**デフォルトの名無しさん** · 2023/05/11(木) 19:37:24.28

CCG！CCG！

**デフォルトの名無しさん** · 2023/05/12(金) 14:15:57.41

終戦のお知らせ

Rust言語で開発されたカーネルがプレビュー版「Windows 11」に - やじうまの杜 - 窓の杜
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1500062.html

**デフォルトの名無しさん** · 2023/05/12(金) 14:19:03.50

解散

**デフォルトの名無しさん** · 2023/05/12(金) 14:25:26.74

カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな

**デフォルトの名無しさん** · 2023/05/12(金) 14:32:56.45

>>341
Rustの成果をC/C++に還流させるフェーズどんどんやってくれ

**デフォルトの名無しさん** · 2023/05/12(金) 14:44:13.86

Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
https://azure.microsoft.com/en-us/blog/microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust/

Rust as the path forward over C/C++

Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time.

**デフォルトの名無しさん** · 2023/05/12(金) 14:45:57.07

マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
https://www.publickey1.jp/blog/23/_rustwindowsinsider.html

デバドラからか

**デフォルトの名無しさん** · 2023/05/12(金) 15:41:33.52

これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
https://m.youtube.com/watch?v=qQXXI5QFUfw

**デフォルトの名無しさん** · 2023/05/12(金) 16:02:52.10

むかしもこんな感じでJ++に騙されたんだよ

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

コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな?

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

Visual Rust++登場も近いな

**デフォルトの名無しさん** · 2023/05/12(金) 16:19:18.80

新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ