Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part25
https://mevius.5ch.net/test/read.cgi/tech/1722354386/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/20(金) 22:19:18.10

**デフォルトの名無しさん** · 2024/09/20(金) 22:22:15.11

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/
Rust Performance Book
https://nnethercote.github.io/perf-book/

**sage** · 2024/09/21(土) 06:46:43.45

>>1
O2

**デフォルトの名無しさん** · 2024/09/21(土) 10:38:37.60

アンチの人はRustスレの邪魔をせずに
こちらへどうぞ

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

**デフォルトの名無しさん** · 2024/09/21(土) 11:45:15.28

変な質問かもしれないけどRustでもUMLのクラス図みたいなものって有効？
必要なケースとしては、プログラムの設計を他者と共有する必要があり、かつ相手は時間をとってコードを詳細に読むわけでなないという場合

今どきUMLという感じかもしれないけど、社内の他のプロジェクトではUMLを (常にではなく、必要に応じて時々) 使っている
Rustのプロジェクトでもこれを求められた場合にどう対応すれば良いのか
型同士の関係 (1対多などの数量関係や呼び出し関係) を説明するくらいはできるけど、継承などオブジェクト指向を意識したところがあるから、Rustのコードの設計を説明するのに必ずしも向かない気もする
こういう、設計を共有するのってみんなどうしてる？

**デフォルトの名無しさん** · 2024/09/21(土) 12:11:46.71

>>6
トレイトをインターフェイスとみなせば (わかりやすいかどうかは置いといて) 一応は成立すると思う。
だけどそういう図を見るくらいなら cargo doc を読んでいくほうがわかりやすいんじゃないかなぁ。
UML が有用なのはシーケンス図とか、抽象度の高い用途のほうでしょ。

**デフォルトの名無しさん** · 2024/09/21(土) 12:37:38.28

開発者が相手ならCargo docは有効だと思う
だけど、説明したいのは構造体やメソッドの使い方じゃなくて、ドメイン側のロジックが適切な型として表現されてるか、それに抜け漏れがないかといった点
それを視覚的に示せるということでクラス図を例に出した
相手はRustのコードに直接触れるわけではないけど、ドメイン側の知識を持ってて、そういう観点からのレビューをしたいという場面

書いてて思ったけど、Rustのenumで表現されてる型がやや表現しづらい？
OOPだとICommandのようなインタフェースを継承させてたけど、その代わりにenum Command にしてるケース
UMLに合うようにRust側のコードをトレイトを使って書き直すのも本末転倒な感じがする

**デフォルトの名無しさん** · 2024/09/21(土) 12:53:36.90

>>8
プログラムとしての合理性とドメイン側のロジックがそれほど一致しないのは普通のことなのでそういう形でレビューする事例は全然聞いたことないな。
特に専門的でプログラマの理解が追っつかないレベルだとドメイン側のロジックに忠実にやるしかないのだろうけど……。

**デフォルトの名無しさん** · 2024/09/21(土) 13:19:40.34

経験的にRustの構造体はデータベース設計のER図が合いそう
ライフタイムの関係で
・構造体のDrop≒レコードのdelete
・参照≒行ロック
みたいなイメージがしやすくて実装とのギャップを減らせると思う
enumはER図だとsubtypeに相当する

**デフォルトの名無しさん** · 2024/09/21(土) 13:46:07.48

テンプレートメタプログラミングに対応してないなら、C++ですら使えないと思う

**デフォルトの名無しさん** · 2024/09/21(土) 14:16:16.53

メタコードでも最終的に具現化されるから大丈夫でしょ
メタの部分はメタのままモデル化しとけばいい

**デフォルトの名無しさん** · 2024/09/21(土) 15:26:24.58

>>6
自分も相手もUMLに慣れてるのならUML使えばいいと思う
リバースエンジニアリングで図を書くのでなければ別に困らない

>>8
>Rustのenumで表現されてる型がやや表現しづらい？
<<enum>>や<<enumeration>>のマーカーをつけるだけ

**デフォルトの名無しさん** · 2024/09/21(土) 16:07:13.97

VS CODEとrust-anlayzerでrustを書いてるんだけど、
if文を1行でこう書きたいんだけど、自動整形で改行されちゃうんだけど、↓を許容する設定の仕方知っている人いたら教えて～
if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 16:47:05.18

rustfmtを使って整形しているのならば
#[rustfmt::skip]

**デフォルトの名無しさん** · 2024/09/21(土) 16:52:58.13

(if 1 == 1 { true } else { false })
let foo = if 1 == 1 { true } else { false };
みたいにカッコで囲むかletで値を受けるならrustfmtのsingle_line_if_else_max_widthが効きそうだけど
裸のifだと設定では無理かも

#[rustfmt::skip]
if 1 == 1 { true } else { false };
でskipするしかない

rustfmtの設定はrustfmt.toml（Cargo.tomlと同じ場所）で
single_line_if_else_max_width = 80
とか書けばいい
参考：github.com/rust-lang/rustfmt/blob/master/Configurations.md

**デフォルトの名無しさん** · 2024/09/21(土) 17:16:34.53

設計図と実物のギャップに比べたら改行がちょっと多い程度の差は
人体に無害だ
だが科学的に無害だとしても人の機嫌を損ねることは許されない

**デフォルトの名無しさん** · 2024/09/21(土) 18:16:59.29

>>14
短絡評価込みだとこれと同一になるはず。
1==1 && true || false;

この形でも長くなりすぎると改行されちゃうけどね。

**デフォルトの名無しさん** · 2024/09/21(土) 18:24:23.07

>>18
それ結果がboolのとき限定だし流石に……

(1 == 1).then(|| true).unwrap_or_else(|| false)

うーん、ないな

**デフォルトの名無しさん** · 2024/09/21(土) 19:05:43.59

boolならif else必要ないやろ

**デフォルトの名無しさん** · 2024/09/21(土) 19:52:13.10

trueのときの値，falseのときの値って意味で書いてんじゃねえかな

**デフォルトの名無しさん** · 2024/09/21(土) 20:44:43.28

>>15
>>16
ありがとう。やっぱり無理かー
InteliJ Ideaではできたのにな。RustRoverはまだ発展途上だし
Zedに期待したいけど、どこまでできるのか

>>21
そういうことです。とはいえbool限定で別の1行書き方があるとしても↓の書き方を1行に整形してほしいということで

> if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 22:18:19.38

>>9
それを一致させるように努力するのが本来のDDDよ
それを放棄したプロジェクトはいわゆる軽量DDDというアンチパターン

**デフォルトの名無しさん** · 2024/09/21(土) 22:31:50.56

>>21
マジかよ
そんな書き方したらあかんやろw

**デフォルトの名無しさん** · 2024/09/21(土) 22:52:39.16

逆に、一致しないように努力させられるのが特許とか知財か
どっちも嫌な努力

**デフォルトの名無しさん** · 2024/09/22(日) 11:14:51.14

どちらの書き方が簡潔に分かりやすいですか？

let result = match () {
_ if 場合1 => 値1,
_ if 場合2 => 値2,
_ if 場合3 => 値3,
_ if 場合4 => 値4,
_ if 場合5 => 値5,
_ => 値その他,
};

let result = if 場合1 {
値1
} else if 場合2 {
値2
} else if 場合3 {
値3
} else if 場合4 {
値4
} else if 場合5 {
値5
} else {
値その他
};

**デフォルトの名無しさん** · 2024/09/22(日) 11:48:01.54

そのifの判定内容はマッチで扱えないものという認識で良い？
例えば値の範囲なら以下のように書く
let b = match(a) {
　// x if x < 0 とも書けるけど冗長
　..0 => "nagative",
　0..10 => "small",
　_ => "many",
}

ifが必要なら、個人的には「その分岐が変数の値に応じて決まる」という意味合いが強ければmatchを、そうでないならifを使う
元のレスだとmatchに渡すものが空だけど、これが単にレスする際に省略したものでなく本当に () をmatchさせようとしてるなら、ifの方が分かりやすいと思う

**デフォルトの名無しさん** · 2024/09/22(日) 12:58:59.11

だね
条件の中身次第

**デフォルトの名無しさん** · 2024/09/22(日) 13:05:19.87

>>26
matchが短く見やすく可読性も良いかな
並んで順に判定することもわかりやすい

**デフォルトの名無しさん** · 2024/09/22(日) 13:13:51.09

内容次第では条件と値のセットを辞書的なもの(BtreeMapやArray)で管理する形にすることもよくある

**デフォルトの名無しさん** · 2024/09/22(日) 15:11:30.55

複おじ君 Rust を 2 年かそこらやっててまだこんなことにこだわってるの

**デフォルトの名無しさん** · 2024/09/22(日) 15:20:32.79

たとえば、動的にメソッドを定義するコードが
どこにも書かれていないことを確認するためにソースコード全体を読む必要はほとんど無いが
妙な書き方をすればそれが必要になる

**デフォルトの名無しさん** · 2024/09/22(日) 15:36:11.10

でその妙な書き方かどうかはどうやって判定すんの

**デフォルトの名無しさん** · 2024/09/22(日) 16:08:33.07

正しくないかもしれない値段で物を売り買いする自由があるんだから
うっかり正しくない判定をしても大して問題ないよね

**デフォルトの名無しさん** · 2024/09/22(日) 16:16:50.01

こう簡単に矛盾すること書けるやつのソースコード見てみたいわ

**デフォルトの名無しさん** · 2024/09/22(日) 19:42:13.27

矛盾したコードを書いた時、Rustなら検知してくれる

**デフォルトの名無しさん** · 2024/09/22(日) 20:01:27.84

コンパイラのレイヤーしか頭に無いバカ

**デフォルトの名無しさん** · 2024/09/22(日) 22:58:14.23

コスプレイヤーのケツしか頭に無い

**デフォルトの名無しさん** · 2024/09/23(月) 00:01:32.19

リスクを取るとか失敗を恐れないことと、矛盾を限りなくゼロに近づけることって
相性悪いよな

**デフォルトの名無しさん** · 2024/09/23(月) 00:43:24.10

ポエ味が過ぎる

**デフォルトの名無しさん** · 2024/09/23(月) 05:09:03.45

そのレベルの判定基準で売ったり買ったりキャンセルする自由がある

**デフォルトの名無しさん** · 2024/09/29(日) 17:53:03.81

全然普及してないね
誰が使ってんの？

**デフォルトの名無しさん** · 2024/09/29(日) 18:08:13.96

https://response.jp/article/2024/08/08/385006.html
ドイツのVectorとHighTec EDV-Systemeは、RustアプリケーションとCベースのAUTOSAR Classic基本ソフトウェアの統合に成功した、と発表した。
これにより、自動車業界でのプログラミング言語「Rust」使用における最後の障害が取り除かれたという。

**デフォルトの名無しさん** · 2024/09/29(日) 18:13:50.86

トヨタもRust技術者を募集してるね

**デフォルトの名無しさん** · 2024/09/29(日) 22:22:20.01

「The Rust Foundation」は、人命や財産に関わるような安全性が決定的に重要になるシステムのために、
Rust言語を責任を持ってサポートするためのコンソーシアム「Safety-Critical Rust Consortium」の設立を発表しました。
設立には日本からWoven by Toyotaが参加

**デフォルトの名無しさん** · 2024/09/30(月) 04:31:41.35

Rustは良い言語だと思うけど
> 人命や財産に関わるような安全性が決定的に重要になるシステム
に効果的なのかはやや疑問

自動運転は詳しくないから財産の方で書くけど、例えばみずほ銀行のシステム障害や仮想通貨取引所からのコインの流出といった問題はRustだと防げてたか？というとそんなことはないと思う
プログラム上のバグは防ぎやすくなるけど、仕様策定時の想定不足や運用の問題までは防げない

**デフォルトの名無しさん** · 2024/09/30(月) 07:15:29.93

プログラム上のバグを防ぎたいと思うからこそ
MISRA C みたいなルール作ってチェックしてるわけで
それを言語仕様で防げるRustを使いたいというのは当然だと思うけど
仕様バグが防げないからといって他のバグも入ってよいわけではない

**デフォルトの名無しさん** · 2024/09/30(月) 07:34:00.91

>>46
プログラミング言語がカバーしない領域の問題を持ち出して来て「Rustはこの問題を防げない！」と主張するバカがときどき現れる
頭が弱いんだろうな

**デフォルトの名無しさん** · 2024/09/30(月) 08:45:28.66

>>48
そういう領域をわざと曖昧にして騙す詐欺師もいるからなんとも。

**デフォルトの名無しさん** · 2024/09/30(月) 09:16:22.72

ああ、>>42みたいなのって定期的に現れてたけどこれも例のネタ振りだったのか
終わりやなあ

**デフォルトの名無しさん** · 2024/09/30(月) 10:02:54.61

>>49
プログラミング言語ではカバーできない領域の問題をわざわざ出して来て
「Rustはこの問題を防げない！」と主張するのが詐欺師
他の言語でも防げないのだからRustにおける問題ではない

**デフォルトの名無しさん** · 2024/09/30(月) 10:32:26.16

>>46
言語機能からくるバグと仕様のバグを区別できてなさそう

**デフォルトの名無しさん** · 2024/09/30(月) 10:54:40.07

Rustで他国の技術者を疲弊させる作戦なのかもな

**デフォルトの名無しさん** · 2024/09/30(月) 11:04:51.09

たしかにTesla/SpaceXが言語選択を前面に出して安全性アピールしたこと無いな

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

言語を全面に出してアピールするのは使える言語しかアピールするものがないカスだけ
他にアピールするものがある人はそっちをアピールする
言語は乗り換える時はしれっと乗り換える

**デフォルトの名無しさん** · 2024/09/30(月) 11:36:23.02

TeslaもSpaceXもRustエンジニア結構募集してるから社内ではしれっと使ってるんだろう

**デフォルトの名無しさん** · 2024/09/30(月) 11:51:09.07

そだねTesla公式ではなさそうだから小規模だったのかと

今の自動運転関係はc/c++/python見たい
Experience programming C/C++ software, including modern C/C++ (C++14/17/20)
Write fleet queries and Python scripts to source new datasets

**デフォルトの名無しさん** · 2024/09/30(月) 12:28:38.91

自分の人生が上手く行かないことを何もかもC++のせいにしてる人がいる気がするよ。
他者を批判することは誰でも簡単に出来るから。

**デフォルトの名無しさん** · 2024/09/30(月) 12:33:20.09

SOの愛され言語がまさにその通りで普及している言語は憎まれ役
逆もしかり

**デフォルトの名無しさん** · 2024/09/30(月) 12:41:53.28

Teslaの様な近視眼的な利益優先の成長企業は次世代言語投資なんてギャンブルしないでしょ

**デフォルトの名無しさん** · 2024/09/30(月) 15:25:54.70

言語に詳しいことを技術力と勘違いしてるやついるよな
そんなの大した価値ないから

**デフォルトの名無しさん** · 2024/09/30(月) 16:37:10.99

そろそろポエム来そう

**デフォルトの名無しさん** · 2024/09/30(月) 18:16:36.18

>>61
Ruby検定ぇ…

**デフォルトの名無しさん** · 2024/09/30(月) 19:11:24.24

>>43のRustから基本ソフトウェアが使えるようになったAUTOSARはテスラ以外の各国の自動車メーカー・部品メーカー・ソフトウェア会社などによって成り立っている

**デフォルトの名無しさん** · 2024/09/30(月) 19:30:44.32

ポエム来たw

**デフォルトの名無しさん** · 2024/09/30(月) 19:40:13.57

全部ポエムだろ

**デフォルトの名無しさん** · 2024/09/30(月) 21:02:02.50

そろそろポエム来そう

……

ポエム来たw

**デフォルトの名無しさん** · 2024/09/30(月) 21:05:21.65

>>52
その違いを区別した上で「現実の問題は仕様や運用から来るものも多く、それについてRustは他の言語以上の力を発揮するものではない」と書いてるんだが

**デフォルトの名無しさん** · 2024/09/30(月) 21:15:05.58

プログラミング言語でカバーできない領域の話をこのプログラミング板で議論しても無意味
一方でその問題のうち言語でカバーする領域の話については反論もないことから様々な点でRustが最善なのだろう

**デフォルトの名無しさん** · 2024/09/30(月) 21:51:49.87

「様々な点」というならそれこそプロジェクトの特性によるだろ
研究者がPythonを使うのや大規模プロジェクトでC#やJavaを使うのだって、それぞれ理由があるわけで

**デフォルトの名無しさん** · 2024/09/30(月) 22:09:35.06

>>69
>プログラミング言語でカバーできない領域の話をこのプログラミング板で議論しても無意味
プログラミング板はプログラミング言語板ではないのだよ、複トン君。

**デフォルトの名無しさん** · 2024/09/30(月) 22:28:02.74

>>70
今回の件のプロジェクトは「人命や財産に関わるような安全性が決定的に重要になるシステムのため」と明記化されているので
もしRustより相応しい言語があるならば、その言語と根拠を参加しているトヨタやIT企業たちに教えてあげればいいんじゃないかな

**デフォルトの名無しさん** · 2024/09/30(月) 22:37:41.53

まず「最も良い言語」というものがあるという考え自体が幻想だと思うぞ
だから自分はRustより良い言語があるだなんて言わない
言語に限らず技術選定というもの全般に言えるけど、それはそれぞれのチームやプロジェクトにおいて判断すべきものであって、言語が先に来るものではない

**デフォルトの名無しさん** · 2024/09/30(月) 22:48:21.43

>>73
それはおかしい
現状Rustが最善であると言語が先に来た上で、足りない所があれば改善や補強などしていくコンソーシアムだぞ
少なくとも言語については他を検討しようにもまともな言語がない

**デフォルトの名無しさん** · 2024/09/30(月) 23:03:53.20

幻想なのは当たり前。
その上で The Rust Foundation は Rsut がベストだという「ことにする」という前提を置いてる。
やってみて駄目だったら前提が間違ってることがわかるだけだ。

やる前にわかるなら苦労しないよ。
比較的マシそうなものでやってみて成功したり失敗するのが進歩ってものだろ。

**デフォルトの名無しさん** · 2024/09/30(月) 23:07:52.86

>>73
その技術選定をした各企業がRustに対して人とお金を出すプロジェクトなのだから言語が先に来るのは当たり前じゃないかな
目的も明確になっているプロジェクトだからもしRustより相応しい言語があるならば各企業に理由と共に教えてあげればいいんじゃないかな

**デフォルトの名無しさん** · 2024/10/01(火) 00:52:01.25

みんな複おじと遊ぶのが大好きなんだねえ

**デフォルトの名無しさん** · 2024/10/02(水) 10:16:15.34

境界値検査しない言語が境界値検査する言語より遅い訳が無い

**デフォルトの名無しさん** · 2024/10/02(水) 12:09:34.85

>>78
ロジハラ禁止

**デフォルトの名無しさん** · 2024/10/02(水) 18:27:24.18

>>78
RustとCやC++の速度比較するベンチマークテストは
全く当てにならない。
実験すれば全て正しいということにはならない。
なぜなら、実験というものは実験条件を整える
のにその科学現象の深い理解が必要であり、
その条件で測定したこと自体は正しくても、
それが本当に知りたいことを測定しているとは
限らないから。

**デフォルトの名無しさん** · 2024/10/02(水) 18:29:04.37

>>80
あくまでも、細かい条件まで含めて完全にその条件で
実験するとその結果が得られた、というだけであり、
「その言語におけるある目的Aを達成するための速度」
を表しているとは限らないから。

**デフォルトの名無しさん** · 2024/10/02(水) 18:31:40.53

実験しなくても、最適化で差が付く以外ではC言語が
最速である、とい事は理屈からも分かっている。
これも理解するためには数式を使った論理を正確
に理解する必要が有り、大体の勘で言っている
ようなことではない。

**デフォルトの名無しさん** · 2024/10/02(水) 18:31:41.82

実験しなくても、最適化で差が付く以外ではC言語が
最速である、とい事は理屈からも分かっている。
これも理解するためには数式を使った論理を正確
に理解する必要が有り、大体の勘で言っている
ようなことではない。

**デフォルトの名無しさん** · 2024/10/02(水) 20:34:56.49

C++でいう非型テンプレートってRustでできる？
std::array<int, 4> の4の箇所のように、型ではなく数値や文字列をジェネリクスに使うやつ

Rustでも配列はコンパイル時にサイズが決まるし、似たような仕組みはありそうに思えるんだけど、見つからなくて
ジェネリクス型の中に配列を持たせるなら Vec などの可変サイズ型が必須？

**デフォルトの名無しさん** · 2024/10/02(水) 21:02:06.37

>>84
だいぶん前から出来るよ。
const キーワードを使う。
https://doc.rust-lang.org/reference/items/generics.html
ただ、現在の C++ よりは制限がきつい。

**デフォルトの名無しさん** · 2024/10/02(水) 21:08:54.46

>>81
横からだけど、そういうベンチマーク結果ってなくない？
同じアルゴリズム、同じPC上での結果なんて、ブログ記事で見るかどうかレベル。

大抵順位が出てるのは他人がバラバラのアルゴリズムで（同じ目標の）コード書いて、同一鯖上でベンチマークした結果ばっかりな気がする。

**デフォルトの名無しさん** · 2024/10/02(水) 21:34:49.26

それぞれの言語で自然な書き方で比較するのもそれはそれでフェアな条件の付け方じゃない？
実際問題としてそれぞれの言語で完全に同一のアルゴリズムで同一の構造になるようなことはないんだから言語の通常の習慣を曲げてまで条件を揃えるのが本当にフェアなルールだとは思わないな。
「普通にやったらこうなる」という比較のほうが日常的なユースケースでは意味のある比較に思える。

処理系を作る側が改善箇所を探す用途のベンチマークだったらまた事情は違うかもしれないけど。

**デフォルトの名無しさん** · 2024/10/02(水) 21:35:48.88

>>85
サンクス
自分はThe Rust Program Language の日本語訳を参照してたけど、こちらには同様の説明が見当たらなかった (単に見落としかも？) ので、適切なリファレンスへのリンクは助かります

**デフォルトの名無しさん** · 2024/10/02(水) 22:06:25.68

>>88
公式読めよ

**デフォルトの名無しさん** · 2024/10/02(水) 22:11:54.22

>>88
そのへんはたぶん英語版でも書いてないと思う。
The Rust Program Language は入門とか紹介という立場なので言語機能を網羅的に説明しているわけではないよ。

**デフォルトの名無しさん** · 2024/10/02(水) 22:13:09.56

>>78
昔とは異なり
必要な境界値検査はプログラミング言語が責任を持って行わなければならない
この必須の機能を持たないC/C++は危険な言語として米ホワイトハウスも安全な言語への置き換えを推奨すると表明している

**デフォルトの名無しさん** · 2024/10/02(水) 23:30:25.01

単純なforで初期値と終了値が確定してるなら
境界超えは有り得ないんだから
そんなのまで境界チェック入れるのはナンセンス

**デフォルトの名無しさん** · 2024/10/02(水) 23:32:21.66

>>92
そこに着目して各個別の境界チェックを無くしてCと同じ速さが出るようにしたのがRustだね

**デフォルトの名無しさん** · 2024/10/02(水) 23:52:48.74

>>93
そうじゃない例が多くてなあ
同じLLVMのZigがRustより早かったしな

**デフォルトの名無しさん** · 2024/10/02(水) 23:59:36.32

あった、前スレ930

Zig 0.107
g++ 0.115
Rust 0.129 (bit-vect)
clang++ 0.131
Go 0.202 (godropbox/container/bitvector)
Rust 0.284 (Vec<bool>)
Go 0.326 ([]bool)

**デフォルトの名無しさん** · 2024/10/03(木) 00:25:43.29

>>94
Zigは境界チェックをしていないダメな言語側なので論外

**デフォルトの名無しさん** · 2024/10/03(木) 00:29:43.46

オプションで境界チェック消すのはRustと一緒じゃん

**デフォルトの名無しさん** · 2024/10/03(木) 00:36:59.84

>>95
よく見たら、これはインデックスでのランダムアクセスが必要なアルゴリズムだから
Rust側はオプションで境界チェック消さないとclangにも追い付かない

ダメな言語側避けると、RustとGoが同レベルなんじゃないかな

**デフォルトの名無しさん** · 2024/10/03(木) 01:45:50.92

>>87
>「普通にやったらこうなる」という比較のほうが
>日常的なユースケースでは意味のある比較に思える。
SNSでRustとC++でベンチマークを書いている人、
C++では、「普通のやり方」が書けてないケースが
ほとんど。
そもそも、C++がCよりも数%を超えるような
大幅に遅い結果が出ている時点で書き方がおかしい。

**デフォルトの名無しさん** · 2024/10/03(木) 01:56:21.29

>>99
妄想じゃないなら参考までに2,3見繕ってくれよ

**デフォルトの名無しさん** · 2024/10/03(木) 01:58:36.94

Rust信者は自分が間違っていることに気付かない。

**デフォルトの名無しさん** · 2024/10/03(木) 01:59:28.46

>>97
Zigは-O ReleaseSafeかDebugの時を除いて境界チェックをしないため危険
Rustは常に境界チェックをするため常に安全
もちろん安全に境界チェックを取り除ける場合は消える

**デフォルトの名無しさん** · 2024/10/03(木) 02:04:50.11

>>102
>>95のRust&clang++場合は、本当は安全だけど境界チェックを取り除けなかったんだろうな

**デフォルトの名無しさん** · 2024/10/03(木) 02:06:36.38

C++でもborrow checkerがcompiler explorerで動いてるし色々動き出すな

Safe C++ Proposal P3390R0

**デフォルトの名無しさん** · 2024/10/03(木) 02:09:42.83

>>103
妄想でないならソースコードとその時の生成コード例を出してみて

**デフォルトの名無しさん** · 2024/10/03(木) 02:15:34.65

?
前スレで出てたgithubとタイム見ただけだから自分で確かめてよネ > 105

**デフォルトの名無しさん** · 2024/10/03(木) 02:15:50.14

先生に対して、仕事を要求する馬鹿な生徒。

**デフォルトの名無しさん** · 2024/10/03(木) 02:16:52.99

>>107の指摘は、>>103 に対することだが。

**デフォルトの名無しさん** · 2024/10/03(木) 02:20:51.39

Rust関係なさ過ぎて熱が冷めたからSafe C++ Proposal P3390R0に移るかな

**デフォルトの名無しさん** · 2024/10/03(木) 02:20:55.67

Rust信者は自分が優秀だと思い込んでいる人が多いらしい。
しかし、実態はそうでもない。

**デフォルトの名無しさん** · 2024/10/03(木) 02:24:53.89

それは良くないw
数時間前のHaskellスレを見てしみじみ思ったw

**デフォルトの名無しさん** · 2024/10/03(木) 02:29:35.48

>>108
「>>103」ではなく「>>100」や「>>105」
だった。スマン。
手間がかかることを人に要求し、それが提示されない
事を持って、相手がうそつきだと認定する手法を
使っている。
詭弁の一種だ。

**デフォルトの名無しさん** · 2024/10/03(木) 02:31:10.25

safecpp.org/P3390R0.html

**デフォルトの名無しさん** · 2024/10/03(木) 02:32:32.82

Rust信者は、どんどんどんどん、間違ったベンチマークや
間違った情報を発信してくる。
それに対していちいち正すことはできない。
次から次へと間違ったうそ情報を垂れ流し続ける相手に
対して、どうして優秀な人材が貴重な時間を割いて正さなきゃ
ならないのか。
それは世界的損失だ。

**デフォルトの名無しさん** · 2024/10/03(木) 02:39:54.40

C++/CLI/CXのかほりがする

>>112
まともな議論はもう無理ぽ

**デフォルトの名無しさん** · 2024/10/03(木) 02:43:43.51

>>114
一人の作者が複数言語書くと熱意に偏りが出るね

その意味ではちょっと前だけどJavaで始まった1brcが他言語にも波及してそれぞれの達人が競い合ってた
Rustはルール違反取られたけどねw

**デフォルトの名無しさん** · 2024/10/03(木) 02:54:00.24

言語によって標準ライブラリの範囲が異なり意味がないのにこのルールだからね

[Rules and limits]
No external library dependencies may be used. That means no lodash, no numpy, no Boost, no nothing. You're limited to the standard library of your language.

**デフォルトの名無しさん** · 2024/10/03(木) 02:58:26.34

Rustでは普通によく使われるこのあたりのライブラリすら使ってはいけないことになる
https://github.com/tumdum/1brc/blob/main/Cargo.toml

**デフォルトの名無しさん** · 2024/10/03(木) 02:58:57.45

最悪のケースだと、こういうところで、最初間違った
ことを散々書いていて、痺れを切らした優秀な人
に時間をかけて情報を提示させ、しれっと
それを論文にまとめて自分の手柄にしてしまうような
不届き者が出てくる。

**デフォルトの名無しさん** · 2024/10/03(木) 06:10:20.97

各IT大手だけでなくホワイトハウスや国防総省までC/C++を捨ててRustへ移行と言っている
少なくともRustと同レベルの安全性を備えない限りこの流れは止まらないだろう

**デフォルトの名無しさん** · 2024/10/03(木) 07:37:36.99

>>118
一つ上のレスのルールを見る限り当たり前じゃね？
「皆が当たり前に使うライブラリ」ならC++のBoostやPythonのnumpyだってそうだろ
しかも >>118 はバージョン1未満のものもあって、それは同じコードが将来動かなくなる可能性があるわけだし

**デフォルトの名無しさん** · 2024/10/03(木) 07:48:32.16

Rustでコードが将来動かなくなる可能性はない
ましてやバージョン1未満かどうかなんて関係ない

**デフォルトの名無しさん** · 2024/10/03(木) 10:29:08.64

バージョンや環境を塩漬けにしてただ動けばいいだけという話じゃないだろ
コードの変更を伴わずに継続的に本番運用できる期間の長さが重要

rust自身やstdのAPIの後方互換性の保証だったり
脆弱性対応の修正数の少なさだったりはいいけど
3rd partyライブラリはそうもいかない

1.0未満はもちろん1.0以降でも
永久に過去バージョンの対応ができるわけでもない

**デフォルトの名無しさん** · 2024/10/03(木) 10:48:04.49

>>99
Cは速いけどC++はどちらかと言うと遅い言語の部類に入る

**デフォルトの名無しさん** · 2024/10/03(木) 10:55:54.38

>>110
本当に優秀ならRust使う必要無いもんな

**デフォルトの名無しさん** · 2024/10/03(木) 11:00:18.13

>>119
chatGPTのことですねω判りますωωω=2πf

**デフォルトの名無しさん** · 2024/10/03(木) 11:06:17.98

>>122
Cargoで管理してればある程度はそうだけど
それも暗黙のルールに期待した場合の話に限るから
絶対描き換えなしで動き続けるかというとそうでもない
最低でもCargo.tomlの描き替えが必要だったりする
この辺はRustの責任ではないがCargoにもRustのメモリ安全ωの姿勢を見習って欲しい

**デフォルトの名無しさん** · 2024/10/03(木) 12:14:17.60

バージョンを指定した
上でCargo.tomlを書き換えなければ
自分で書いたソースコードは外部ライブラリに影響されずに永久に動くところがRustの利点なんだよ

**sage** · 2024/10/03(木) 12:33:12.38

>バージョンを指定した上でCargo.tomlを書き換えなければ
>自分で書いたソースコードは外部ライブラリに影響されずに永久に動く

version = "0.1.0"
じゃなくて
version = "=0.1.0"
と描いた場合に限る

**デフォルトの名無しさん** · 2024/10/03(木) 12:34:26.98

version = "0.1.0"
だと
外部ライブラリに影響される

外部ライブラリに影響されないのは
暗黙のルールに期待した場合の話に限る

**デフォルトの名無しさん** · 2024/10/03(木) 12:36:20.68

もちろん
version = "=0.1.0"
と描くのは現実的ではないが
>バージョンを指定した上でCargo.tomlを書き換えなければ
を満たすための矛盾

従って"暗黙のルールに期待した"Cargoは糞

**デフォルトの名無しさん** · 2024/10/03(木) 13:08:08.08

繰り返し構文の直前だけで行うように最適化されたにしろ
Rustだと配列の範囲をはみ出してないかの検査が
リリース版アプリでも入り続けるのだろうが、
それで不合格になるとアプリはダウンするから、
自動運転では人が死ぬので意味無い。

**デフォルトの名無しさん** · 2024/10/03(木) 14:18:38.46

>>131
>>128の文章が足りてないだけで
そこはCargo.lockの担当範囲やろ

**デフォルトの名無しさん** · 2024/10/03(木) 18:08:46.17

おまいら愚痴ってないでcode書け
書いて書いて書き捲れ

**デフォルトの名無しさん** · 2024/10/03(木) 21:40:37.20

>>124
C++で遅いというなら「どちらかというと速い言語」って何が残るんだ

**デフォルトの名無しさん** · 2024/10/04(金) 17:31:48.28

ざっくり速い遅いとか言ってるやつは雑魚でしょ
相手しなくていい

**デフォルトの名無しさん** · 2024/10/04(金) 22:11:50.25

十倍とか百倍とかいうレベルで露骨に差があるものならざっくりした比較でいいよ。
細かい数値が必要になるのは差が微妙だからで、その微妙な差を素人が適切に評価できるんかって話だわ。
データを出したってどうせそのデータを適切に読み取るのは無理だ。

そりゃ Rust が実行時にも境界チェックをする場合がある (実行コストが上がる) のは本当だけど、
Rust のほうが C++ より最適化しやすい (エイリアス解析がやりやすいので) というのはあるし、
その一方ではまだ C++ の処理系のほうが歴史の積み重ねが多くて強いというのもある。

ざっくりは無意味だが細かい数値も要因が絡み合いすぎてどうせ意味わからんから無意味。

**デフォルトの名無しさん** · 2024/10/04(金) 22:21:16.42

>>136が言ってるのはそういう「ざっくり」ではないと思われ

**デフォルトの名無しさん** · 2024/10/04(金) 22:40:51.60

ざっくりどころか明白にC++はCより遅いしRustはさらにもっと遅い

**デフォルトの名無しさん** · 2024/10/04(金) 22:59:19.40

C以外を全て「遅い部類」というならもうそれ部類って言葉が合わないんじゃないかな

**デフォルトの名無しさん** · 2024/10/04(金) 23:37:34.19

ほとんどのケースでRustはCと同程度の速さを出せる
安全性はもとよりモダンな抽象による開発効率と保守性の高さによりRustへの移行が進められている

**デフォルトの名無しさん** · 2024/10/05(土) 10:53:01.80

BoxやVecって、データを一旦スタックに書いてからヒープに渡されるよね
Bnx::new(でかい構造体)
のようなことをやる際に、直接ヒープに構築したいんだけど、unsafeを使えばできる？

**デフォルトの名無しさん** · 2024/10/05(土) 11:04:55.83

>>142
box演算子を使う

**デフォルトの名無しさん** · 2024/10/05(土) 13:18:05.42

>BoxやVecって、データを一旦スタックに書いてからヒープに渡されるよね
うそーん？
そのくらいは最適化されるやろ？

**デフォルトの名無しさん** · 2024/10/05(土) 14:23:20.89

>>141
そんなこと言う人は多いけど、その人たちはアルゴリズムを理解してない。

**デフォルトの名無しさん** · 2024/10/05(土) 15:12:54.52

Rustは境界検査ある分Cよりは遅くなるよね
境界検査オフにしたらベンチマークのスコア上がったみたいな記事がZennにあった気がする

**デフォルトの名無しさん** · 2024/10/05(土) 15:18:00.36

そんなことしたらコーダーが勝手に最適化()するから駄目だろ。

**デフォルトの名無しさん** · 2024/10/05(土) 16:20:58.85

>>146
Rustに境界検査オフにするオプションはないからそれは別の言動の話でしょう
Rustでは常に行われますが論理的に安全だと判定できる場合に最適化されて消えます

一方で境界検査がない言語では必要な境界検査をプログラマーが手動でする必要があります
それを忘れると深刻なセキュリティホールになる可能性があります
レアな特殊な状況が揃って初めて発生することもあるためサニタイザーでは見つけることが困難です

**デフォルトの名無しさん** · 2024/10/05(土) 17:01:50.15

>>143
詳しく
"box operator" のような単語でググってみたけど、それらしいものを見つけられてない

**デフォルトの名無しさん** · 2024/10/05(土) 17:08:36.51

>>148
get_uncheckedとかあるやろ

**デフォルトの名無しさん** · 2024/10/05(土) 17:33:09.63

>>149
少なくとも stable には無い。
現時点では box が予約語扱いになってるが、将来に使用するための予約であって現時点では使ってないと名言されてる。
https://doc.rust-lang.org/reference/keywords.html

以前に検討したけど取り下げた記録はある。
https://rust-lang.github.io/rfcs/0809-box-and-in-for-stdlib.html
今はどうなってるんやろね？

**デフォルトの名無しさん** · 2024/10/05(土) 17:40:46.65

× 名言
〇明言

**デフォルトの名無しさん** · 2024/10/05(土) 17:53:26.30

>>146
分かりやすさから境界検査だけの遅さは分かっている
人が多いが、実は境界検査は些細な違いに過ぎない。
それ以上の事は言わない。各自で考えろ。
分かる人だけが分かっていればいい。

**デフォルトの名無しさん** · 2024/10/05(土) 22:25:00.84

https://github.com/rust-lang/rust/pull/97293や
https://github.com/rust-lang/rust/pull/108471が
現状なんかな？

**デフォルトの名無しさん** · 2024/10/05(土) 23:58:02.93

たしかbox記法をやめて
#[rustc_box]へ変えたはず

**デフォルトの名無しさん** · 2024/10/06(日) 02:23:22.08

>>142
今は
let mut b = Box::<BigStruct>::new_uninit();
とする

**デフォルトの名無しさん** · 2024/10/06(日) 02:59:36.25

ボツになった box キーワードを使ったやりかただと C++ でいう new みたいなのを想定していたんだと思う。
同じコンストラクタでスタック上にもヒープにもオブジェクトを構築できるようにってことね。
今の Rust の stable 内でやろうとすると未初期化のヒープ領域を確保してからそれに書き込むという段階を踏む必要があって同じ生成関数をキーワードひとつで切り替えてつかうということは出来ない。
そういうちょっとした不恰好さを呑む必要はある。

**デフォルトの名無しさん** · 2024/10/06(日) 10:41:43.35

>>156
コンパイラや標準ライブラリの開発者は#[rustc_box] + Box::new()を使うのに一般開発者はBox::new_uninit() + unsafeブロックで手動初期化しなきゃいけないというのはなんとも微妙だね

**デフォルトの名無しさん** · 2024/10/06(日) 11:07:22.09

>>153
わかってないやつが言っても説得力ないよ

境界検査を外す話はこれかな
https://proc-cpuinfo.fixstars.com/2019/09/rust-wins-cpp/

**デフォルトの名無しさん** · 2024/10/06(日) 13:00:12.28

>>159
実行毎に数十msはブレる処理でC++より数ms速くなりましたとか微妙すぎるな

**デフォルトの名無しさん** · 2024/10/06(日) 14:13:57.31

>>160
同感、20~40msはぶれる

>>159
Rustシングルスレッド版のcommit:23807a67df266ac8c6ba065801616a4012555344に戻して
単一実装毎に10回計測した最速値

SequentialNative, PreProcess, 3.328, Solve, 767.845, PostProcess, 0.521 <- C++/g++
SequentialNative, PreProcess, 3.679, Solve, 785.951, PostProcess, 0.502 <- C++/clang++
Rust, PreProcess, 3.407, Solve, 796.38, PostProcess, 0.599 <- Rust

**デフォルトの名無しさん** · 2024/10/06(日) 14:32:01.49

一番下の方にリンクしてあるQiitaの追試記事も読むといい

**デフォルトの名無しさん** · 2024/10/06(日) 14:47:13.76

>>159
「検査例外は些細な違いに過ぎない」
と言ったのは、Rustには、もっと非効率な部分があるからだぞ。
逆に捉えた人がいるかもしれないが。

**デフォルトの名無しさん** · 2024/10/06(日) 14:48:25.28

>>163
誤:検査例外
正:境界検査

**デフォルトの名無しさん** · 2024/10/06(日) 22:43:06.06

Rustコンパイラが通常の機能として論理的に安全と解析できた時は境界検査を省略しているのに加えて
プログラマーがさらにヒントを与えることで境界検査を安全に無くしたり減少させたりする方法もありかなりをカバーできる
それでもカバーできない範囲は人間が安全性を保証する形でunsafeを用いて関数やモジュール内に閉じ込める最後の手段がある
プログラムのそれ以外の部分は依然としてRustが安全性を保証するためRustを用いたほうが断然に有利

**デフォルトの名無しさん** · 2024/10/06(日) 22:58:46.94

相変わらず非論理的やな

**デフォルトの名無しさん** · 2024/10/07(月) 01:41:44.93

基本をどっち側に倒してるかって話だわな。
チェックするのを基本にする (けど必要ならチェックを除くことも出来る) のか
チェックしないのを基本にする (けど必要ならチェックすることも出来る) のかって話で、
やりやきゃどっちも出来るんだから場合によって自分で判断しろよ。

**デフォルトの名無しさん** · 2024/10/07(月) 02:43:52.62

これはさすがに釣りだよね

**デフォルトの名無しさん** · 2024/10/07(月) 04:55:29.89

もしかしてRustってコンパイルめちゃくちゃ遅い？

**デフォルトの名無しさん** · 2024/10/07(月) 10:41:01.74

一回コンパイル済みなら、2回目はそれなりの時間

初回のsdk-ec2は遅すぎて何度中断しようかと思ったわ

**デフォルトの名無しさん** · 2024/10/07(月) 15:40:05.30

cargo update するとすぐ破綻する

**デフォルトの名無しさん** · 2024/10/07(月) 16:27:42.48

sccacheで二度目以降はもう少し改善した
コンパイル速度はC++同様遅い部類だと思う

**デフォルトの名無しさん** · 2024/10/07(月) 17:01:46.54

>>163
それの具体例を示せてない時点でね…

**デフォルトの名無しさん** · 2024/10/07(月) 23:19:03.68

安全に境界検査不要をassert!でRustコンパイラに伝える方法が意外に効くね

**デフォルトの名無しさん** · 2024/10/07(月) 23:26:15.84

>>173
馬鹿には示す必要ない。

**デフォルトの名無しさん** · 2024/10/08(火) 08:44:17.05

>>174
詳しく

**デフォルトの名無しさん** · 2024/10/08(火) 09:34:58.32

自分で定義してないtrait(T)を自分で定義してないstruct(S)に定義したい
impl T for S {
}

**デフォルトの名無しさん** · 2024/10/08(火) 10:04:39.98

>>177
できないのでどちらかをwrapして下さい

**デフォルトの名無しさん** · 2024/10/08(火) 10:36:24.86

>>177
orphan rule と呼ばれる制限。
どうしてこの制限が必要なのか、対処法のイディオムなどはググればいっぱい説明されてるよ。

**デフォルトの名無しさん** · 2024/10/08(火) 21:24:47.85

>>175
知らないだけw

**デフォルトの名無しさん** · 2024/10/08(火) 21:26:47.09

>>180
やっぱり本当に馬鹿なんだな。
それに説明しても理解できない。

**デフォルトの名無しさん** · 2024/10/08(火) 23:19:20.44

>>176
https://nnethercote.github.io/perf-book/bounds-checks.html

**デフォルトの名無しさん** · 2024/10/09(水) 08:10:07.07

>>182
thx

**デフォルトの名無しさん** · 2024/10/09(水) 14:24:59.18

慈円乙

**デフォルトの名無しさん** · 2024/10/09(水) 18:17:45.48

>>175
あーあ，反ワクが自分で調べてくださいっていうのと同じか
自分で説明するとボロが出るから

**デフォルトの名無しさん** · 2024/10/09(水) 21:57:24.09

実験と質問の境界がなくなりかけている
質問なら自己解決もありうる
実験の場合、自分で考えた実験結果というのはただのデータ改竄

**デフォルトの名無しさん** · 2024/10/09(水) 22:10:40.53

>>185
もしかして7回も打ってるの？

**デフォルトの名無しさん** · 2024/10/09(水) 23:54:32.05

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/10/10(木) 02:18:50.02

>>188
Rustには権力による圧力が入ってきている。
市場経済、自由選択への権力介入だ。

**デフォルトの名無しさん** · 2024/10/10(木) 02:21:09.33

コンピュータの分野は権力介入が少なかったので、面白かったのに、
政治家やマスコミが入り込んできてめちゃくちゃになってきている。

**デフォルトの名無しさん** · 2024/10/10(木) 07:08:10.03

与党が介入するなら野党に投票すればいい

**デフォルトの名無しさん** · 2024/10/10(木) 09:15:33.28

コンピュータープログラムのアルゴリズムごときでノーベル賞とか
最近はホント可笑しい

**デフォルトの名無しさん** · 2024/10/10(木) 09:54:14.90

ソフトウェア特許がろくでもないのでノーベル賞みたいな形のほうがマシだと思う。
良いとは言えんが。

**デフォルトの名無しさん** · 2024/10/10(木) 21:54:50.97

>>189
米政府は危険なC/C++を早く捨てて安全なプログラミング言語を使うことを推奨するとして、Rustを含めた複数の安全な言語を挙げているので大丈夫だよ。
ただしRust以外はガベージコレクション言語なので、C/C++と同等の速さやメモリ使用量を望むならばRustしか安全な言語の選択肢がない。

**デフォルトの名無しさん** · 2024/10/11(金) 00:11:00.19

AIと人間が競争するみたいな文脈では危険といえば相手に負けることしか思いつかなくなる
それ以外の安全性がどうでもよくなる

**デフォルトの名無しさん** · 2024/10/11(金) 01:44:19.33

>>194
結局、C/C++だけが潰される。

警備員[Lv.1][新芽] · 2024/10/11(金) 09:35:58.81

rustはガベコレはないけど、オブジェクトのライフタイムをコンパイル時にチェックして c++でいう deleteを自動でセットしてくれるのですか?
コンパイラはそんな複雑なことができて、結果も信頼できるのでしょうか
それとも、開発者が自由に書けないくらい、書き方に制約を設けてコンパイラにとって既知のパターンとなるようにしているのですかね

**デフォルトの名無しさん** · 2024/10/11(金) 10:48:59.08

>>197
まずはChatGPTにでも聞いて概要を理解しろ

**デフォルトの名無しさん** · 2024/10/11(金) 13:50:24.29

>>197
これはプログラム経験が浅いマネージャに聞かれそうな質問
まずC++のデストラクタを理解してるかどうかがポイントだな

「c++でいうdeleteを自動でセット」というフレーズから不穏なオーラを感じる

**デフォルトの名無しさん** · 2024/10/11(金) 13:54:54.08

>>197
別に複雑なことはしていない
所有権の移動に厳密なだけ