Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

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

**デフォルトの名無しさん** · 2024/08/04(日) 18:28:12.58

フラグメンテーションの問題とかもあるから教科書通りの2倍固定よりも
Goのようにサイズが大きくなるにつれGrowth Factorも小さくしていくモデルのほうが一般的には良さそうだね

**デフォルトの名無しさん** · 2024/08/04(日) 18:43:06.42

gccでもclangでもC++のvectorは2倍にしていくから
これはRustの話ではなくて
2倍にしていくのが好ましいという長年の確立された知見が存在しているんだよ

**デフォルトの名無しさん** · 2024/08/04(日) 18:44:03.04

一方でガベージコレクション依存言語は内部のメモリ管理方式が全く異なるから
各言語個別の事情があるかもしれないけどこのスレの話題ではないね

**デフォルトの名無しさん** · 2024/08/04(日) 19:01:06.46

>>16
それらの言語は仮想メモリを持たない環境のことも考慮しての増加率なんだろうな

**デフォルトの名無しさん** · 2024/08/04(日) 19:12:09.84

仮想メモリを持たない環境でGC言語www

**デフォルトの名無しさん** · 2024/08/04(日) 19:40:14.37

思い込みの激しい人だこと

**デフォルトの名無しさん** · 2024/08/04(日) 19:41:13.70

Vecのアロケート戦略なんて標準ライブラリの実装レベルの話でしかないし、言語の特徴や優劣のような話でもないだろ
GoやJavaが2倍でも、逆にRustがより小さい値だったとしても、GCの有無とかの話に比べればずっと些細な話でしかないし
マジでなにいってるんだこいつとしか思えない

**デフォルトの名無しさん** · 2024/08/04(日) 19:48:10.28

>>25
Javaなんかはもともと組み込みをターゲットに開発された言語だね。
GCの有無と仮想メモリには何の関係もない。

**デフォルトの名無しさん** · 2024/08/04(日) 20:16:30.17

この議論
元々メモリ無駄食いのGC依存言語は無視してよくて、
Rustと同じジャンルのC++で長年議論されてきて2倍という結論が出ている。
どうしても2倍を批判したいならまずはgccやclangのC++に対して行なうとよいかと。

**デフォルトの名無しさん** · 2024/08/04(日) 20:31:51.43

2倍に対して突っ込んでるんじゃなくて延々と的外れなことを書いてることに対して突っ込まれてるだけでは？
平均的なコピー回数が少ない点で2倍は妥当ではあるけど、それも「よく使われる方法」くらいの意味しかない
C++でもMSVCだと1.5倍だったと思うし (今のバージョンでもそうかは未確認)

警備員[Lv.18] · 2024/08/04(日) 21:44:51.68

先生！チャンクアロケーター沼への入水希望者がこんなに

**デフォルトの名無しさん** · 2024/08/04(日) 22:06:56.31

>>21
Goがなぜそんなやり方をしているのか
実行しながら実メモリ使用量の変化を傍らでウォッチして見た
Goの大きなsliceでcapacityが増える時に実メモリ使用量が急激に増える
C++やRustではcapacityが増えてもそんな変動は起きない
つまりGoはこの問題のため2倍ではなく1.25倍にせざるをえないと思われる

**デフォルトの名無しさん** · 2024/08/05(月) 00:28:29.24

>>16の主張が間違っていた可能性があるな
例えば世代別GC各管理領域も拡張再編などが起きるため
C++/Rustとは状況が異なり
増やしたメモリ領域への書き込みがすぐに生じて実メモリ使用量が一気に増えてしまうのかもしれない

**デフォルトの名無しさん** · 2024/08/05(月) 02:39:57.82

C++で folly::fbvector を開発したFacebookによれば
成長係数2は最悪であることが数学的に証明されてるらしい
結論は1.5

https://github.com/facebook/folly/blob/main/folly/docs/FBVector.md

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56

**デフォルトの名無しさん** · 2024/08/05(月) 05:37:35.60

>>34
読んでみたが色々とおかしい
まず1.5倍がベストな理由が書かれていない
次に2倍が悪い理由の説明と現実が合っていない

書かれている2倍が悪い理由を具体的な数字で書いてみると
例えばベクタの使用メモリサイズが育っていって1GBになっている時に
過去に使った半分の512MBの空きが抜け殻としてあり
さらにその前の分として半分の256MBの空きもありそれが過去に繰り返されていて
512MB + 256MB + 128MB + 64MB + ...
= 1GB未満のの再利用できていないメモリがあることになる
つまり再利用ができていないために合わせて約2GBのメモリを確保しているにも関わらず使っているのは半分の1GBなってしまう

という2倍が悪い理由が書かれている
しかしこれは現実と異なる
実際にベクタをゼロから地道にプッシュしていきそのサイズが1GBになった時
確保しているメモリサイズを調べると1GBである
再利用できていない昔の抜け殻が計1GB弱残るという話が現実と合っていない

**デフォルトの名無しさん** · 2024/08/05(月) 07:22:04.78

mmap/munmapでOSにメモリを返却できるから古い抜け殻は残らない
さらにmremapで実コピーをせずに利用可能サイズを増やすことができる
それらを呼び出すコストがかかるためその頻度が1.x倍より少なくなる2倍が好ましい

**デフォルトの名無しさん** · 2024/08/05(月) 12:04:08.00

話が難しいから何を言っているかじゃなくて誰が言ってるかでしか判断出来ねえ
そして5chをソースにfollyのreadmeを否定する意見を信じることも出来ねえ

**デフォルトの名無しさん** · 2024/08/05(月) 12:25:55.60

話は聞かせてもらった
最適な比率は2でも1.5でもなく黄金比1.618だな
こういう問題は大体フィボナッチ数列が正解になる
僕は数学に詳しいんだ

**デフォルトの名無しさん** · 2024/08/05(月) 12:37:42.98

>>37
わかる
もうちょいライトなユーザ向けのスレも欲しいかも

**デフォルトの名無しさん** · 2024/08/05(月) 12:46:25.51

>>37
むしろ彼しか問題にしてないだろ
g++とclang++のvectorとrustcのVecは2倍にしていく
もし2倍が致命的なら大論争になり変更されるはずだ
現実には実用面も含めて問題となっていない

**デフォルトの名無しさん** · 2024/08/05(月) 13:06:57.87

「致命的」に後退しちゃったねｗ

**デフォルトの名無しさん** · 2024/08/05(月) 13:12:56.68

Linux などのメモリ管理戦略ではアロケータは空いてる番地を返すだけで
アクセスするまで実メモリの割り当てをしない。 (割り当てを遅延させる。)

vector を極端に伸ばしたり縮めたりするなら話は別だが、
徐々に伸びていって最後に捨てる一般的なユースケースなら
倍率はテキトーでも理論的な効率はそんなに差はない。

**デフォルトの名無しさん** · 2024/08/05(月) 13:21:17.66

rustやc++では再割り当てが行われると参照が無効になるから2倍にして頻度を下げるのかも

**デフォルトの名無しさん** · 2024/08/05(月) 14:50:20.61

https://github.com/rust-lang/rust/issues/29931
これだね
2015年から議論されてるけど、結局1.5倍がいいという結論には至ってないし
実際1.5倍を試してみた結果パフォーマンスが落ちてるから単純に1.5倍にするのはダメそう
もし1.X倍でパフォーマンス上がる方法があるならそのissueに報告すれば採用されるかもよ

**デフォルトの名無しさん** · 2024/08/05(月) 15:01:05.36

>>44
rustcがベンチマークのネタに適してないんじゃないの？

**デフォルトの名無しさん** · 2024/08/05(月) 15:14:32.99

>>45
そう思うならrustc以外のアプリでベンチ取って提示してみれば？
少なくともパフォーマンス低下するアプリが一つ示されたんだからそれ以上のデータ出さないと話進まないでしょ

**デフォルトの名無しさん** · 2024/08/05(月) 15:48:02.67

もっと歴史の長いGCCのC++もClangのC++もvectorの再割り当ての長さ2倍を採用している
そしてGCを用いてメモリ管理する言語は各々で諸事情があるようだから参考にできない

**デフォルトの名無しさん** · 2024/08/05(月) 16:04:04.60

fbvectorの話はアロケータが確保する単位に合わせて無駄を無くすということと
Vecのリサイズによって開放されたメモリ領域を再利用しやすくするということが書いてるだけ

どっちも理にかなってる

**デフォルトの名無しさん** · 2024/08/05(月) 16:26:39.60

標準として提供する機能には平均的な性能が高いよりも
最悪の場合でもそれなりの性能が出るほうを優先するみたいな考え方もあるし
設計思想にもよるわな。

**デフォルトの名無しさん** · 2024/08/05(月) 18:42:38.74

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56
C++の結果だけど結構な差が出てる
この人のコードを自分の環境でも試してみたがpush_backで5倍前後違う

単純に1.5倍固定じゃなくて真似したやつで試してみたらいいのにね

**デフォルトの名無しさん** · 2024/08/05(月) 19:15:50.62

>>50
ソース見てみたけど恣意的に10倍ずつ異なる長さで順にアロケーションを汚染していき
vectorは単発使い捨てで毎回残らないからその前の残骸の空きエリアにたまたま上手くマッチするかの勝負になっていて
現実とはかけ離れたテストになっていると思った

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

>>49
速度vsメモリ効率なんかもあるしね

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

>>50
こんなに違いが出るのか

**デフォルトの名無しさん** · 2024/08/06(火) 00:27:44.41

>>44を読んでると
1.5倍にすると実用なプログラムでは遅くなるのに対し
>>50の特殊なベンチな時だけ1.5倍がとても速い理由は
他のメモリ割り当てに邪魔されずに1つのベクタだけがどんどん成長していくからで
1+1.5+1.5^2+1.5^3 ＜ 1.5^4 であるため
自分が過去に用いたところを結合してそのまま使えるため速いらしい
しかし現実のプログラムは他のヒープ利用も間に起きるためその再利用はうまく行かずメリットが起こらないと

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

2.71828倍が良いとおもいますん

**デフォルトの名無しさん** · 2024/08/06(火) 13:40:39.24

1.14514倍で

**デフォルトの名無しさん** · 2024/08/06(火) 17:53:14.98

C++が1.5倍伸長のFBVectorで自分の抜け殻を上手く再利用する件
Rustはなぜ2倍伸長でもっと速いのかを調べてみた

同じように他に邪魔されず伸長していくケースだと
RustのVecは以下のように
128Kバイトまでは同じアドレスのまま移動せずにコピー無しで2倍伸長していく
256Kバイト以上ではmremap利用でアドレスは移動するがコピー無しで2倍伸長していく
そのためRustのVecは2倍伸長でもサイズが巨大になっても速いことがわかった

addr=0x5642549e6ab0 cap=8 len=1+1
addr=0x5642549e6ab0 cap=8 len=2+1
addr=0x5642549e6ab0 cap=8 len=4+1
addr=0x5642549e6ab0 cap=16 len=8+1
addr=0x5642549e6ab0 cap=32 len=16+1
(途中略) 【アドレスはずっと変わらない】
addr=0x5642549e6ab0 cap=32K len=16K+1
addr=0x5642549e6ab0 cap=64K len=32K+1
addr=0x5642549e6ab0 cap=128K len=64K+1
【ここでアドレスが変化＆mremap利用が始まる】
addr=0x7f661c06f010 cap=256K len=128K+1
addr=0x7f661bfee010 cap=512K len=256K+1
addr=0x7f661beed010 cap=1M len=512K+1
addr=0x7f661bcec010 cap=2M len=1M+1
(以降略)

**デフォルトの名無しさん** · 2024/08/06(火) 18:25:14.08

もちろんVecは2倍伸長をアロケータにリクエストするだけなので
実際に処理しているのはRust標準のGlobalアロケータ
この環境では出来たバイナリにglibcのmallocやreallocがリンクされてるので最終的にはそこに行き着くはず

**デフォルトの名無しさん** · 2024/08/06(火) 19:53:13.46

Carbon Languageに期待

**デフォルトの名無しさん** · 2024/08/06(火) 20:16:16.47

Rustの標準アロケータを使わずに
>>57をjemalloc利用でアドレス変化を調べると全く異なる結果となった

8Kバイトまではアドレスが毎回変わりコピー移動
16Kバイトから1Mバイトまではアドレスが変わらずコピー無し
2Mバイト以上はアドレスが毎回変わりmremapが使われてないためコピー移動

少なくとも今回の前提での利用の範囲内ならば
Rust標準をそのまま用いるのが最適となる

**デフォルトの名無しさん** · 2024/08/06(火) 20:54:39.49

そういや一昔前、jemallocを採用してるから
Rustは良いんだよ、って主張があったよね

**デフォルトの名無しさん** · 2024/08/06(火) 21:01:13.77

jemallocは色々と問題もあるため5年半前の2019年1月のRust1.32で標準採用しなくなった
もちろんjemallocが好ましいケースもあるのでその時は各自で簡単に使えるようにもなってる

**デフォルトの名無しさん** · 2024/08/07(水) 00:45:04.42

未だに Vec::new_in() が安定化しないRustとは対照的に
Zigはヒープ使う関数すべてで毎回毎回アロケータを引数に渡させて
毎回毎回成功したか確認させるんだね

Linuxカーネル開発にはZigの方が向いてるんじゃなかろうか？

**デフォルトの名無しさん** · 2024/08/07(水) 01:13:06.44

{C++ std::vector, C++ fbvector, Rust std::Vec} × {jemalloc, glibc malloc, LLVM libc malloc, msvc malloc, musl libc malloc} × {Linux, macOS, Windows} × {x86_64, 仮想メモリの機能を持たない何らかのアーキテクチャ}

壮大な議論になってきたなあ
これ全部検証するつもり？

そういやglibc mallocは環境変数でヒープとmmapのどっちを使うかの閾値調整できるとか
msvc mallocは_DEBUGマクロが定義されていると確保したメモリに未初期化を表すバイトを書き込むとかもあった

条件はいくらでも付け加えられそうやね

**デフォルトの名無しさん** · 2024/08/07(水) 01:28:00.75

サイズの大きなベクタは
キャパシティ拡張してもコピーが発生しないmremap利用のアロケータが有利という結論だな
サーバなどで一般的に使われるLinux環境ならRust標準でその条件を満たすから大丈夫

**デフォルトの名無しさん** · 2024/08/07(水) 08:32:07.19

>>63
Zigはまぁ1.0にならないと検討の俎上にもあげられないし
Cと比べてそれほど強い保証が得られるわけでもないから
あまり導入するモチベーションもなさそう

**デフォルトの名無しさん** · 2024/08/07(水) 22:36:11.64

https://www.publickey1.jp/blog/24/rustservowebverso.html
2024年8月6日
欧州を基盤にオープンでセキュアなインターネットの実現を支援しているNLnet Foundationは、
昨年(2023年)末から、Linux Foundation傘下でRust製のクロスプラットフォーム対応Webブラウザエンジンとして開発が進められている「Servo」を用いたWebブラウザ「Verso」の開発プロジェクトの立ち上げを発表した。
また、この「Servo」をTauriの組み込みのWebViewとする方向で開発が始まっている。
Chromiumに代わるRust製

**デフォルトの名無しさん** · 2024/08/07(水) 22:38:49.83

>>67
名前がダサすぎるからダメ

**デフォルトの名無しさん** · 2024/08/08(木) 05:28:31.41

ChromiumがC++のメモリ管理ミスで度々セキュリティ脆弱性を招いてるから
対抗馬ができるのは良いこと

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

まともに動くまで20年ぐらい掛かるんだろ

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

Firefox先生の明日はどっちだ

**デフォルトの名無しさん** · 2024/08/09(金) 06:14:59.59

Tauri2.0 Android/iOSでマルチwebviewしたかった
この流れだとVersoになるまで出来なさそう

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

タウリン実際どうなん？
実用になる？

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

>>73
有用だけど場合による。

**デフォルトの名無しさん** · 2024/08/09(金) 17:08:58.86

implementation of `From` is not general enough
= note: `From<&'0 Hoge>` would have to be implemented for the type `Fuga<'_>`,
for any lifetime `'0`...
= note: ...but `From<&'1 Hoge>` is actually implemented for the type `Fuga<'1>`,
for some specific lifetime `'1`

これはどうやって解決するのが普通？

**デフォルトの名無しさん** · 2024/08/09(金) 17:13:42.47

こういう実装は書いてあります
impl<'a> From<&'a Hoge> for Fuga<'a> {
fn from(src: &'a Hoge) -> Fuga<'_> {
Fuga::from(なんかの変換(src))
}
}

**デフォルトの名無しさん** · 2024/08/09(金) 17:18:10.35

fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge> {
中身
let m = T::from(hoge);
中身
}

みたいな関数を呼んだ(コンパイル時)ときに >>75 のエラーで止まります

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

呼ぶ方は
let x = moge::<Fuga>(2, 5);
みたいに呼びたいのです

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

fn mame(a: &str, b: &str) -> i64 {
中身
let m = Fuga::from(hoge);
中身
}
としたときは正常にコンパイルも動作もできました

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

>>77
全体が見えないのでなんとも言えないが
>>75のエラーを解決するなら
例えば
fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge>
↓
fn moge<'a, T: 'a>(a: &str, b: &str) -> i64 where T: From<&'a Hoge>

**デフォルトの名無しさん** · 2024/08/09(金) 19:57:46.44

`src` does not live long enough
--- argument requires that `src` is borrowed for `'a`
borrowed value does not live long enough
`src` dropped here while still borrowed

**デフォルトの名無しさん** · 2024/08/09(金) 21:05:31.98

playgroundに再現する最小限のコードを貼れよ

**デフォルトの名無しさん** · 2024/08/09(金) 21:17:17.11

タウリンで作られたなんか実用的なアプリある？

**デフォルトの名無しさん** · 2024/08/09(金) 23:57:36.49

>>83
https://github.com/tauri-apps/awesome-tauri

**デフォルトの名無しさん** · 2024/08/10(土) 00:51:32.88

>>84
なんか中国人が多いな

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

先月の航空業界や病院に政府機関など850万台のWindows端末が影響を受けた世界的な大規模システム障害について、
CrowdStrikeが根本原因分析のレポートを発表しました。

「コンテンツインタープリターは20個の値しか想定していませんでした。
したがって、21番目の値にコンテンツインタープリターがアクセスしようとすると、入力データ配列の末尾を超えて領域外のメモリが読み取られ、
その結果システムがクラッシュしました」と報告しています。

記事
https://gigazine.net/news/20240809-crowdstrike-root-cause-analysis/

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

>>86
Windowsやマイクロソフトは何も悪くなかったのか

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

>>86
Rustを使っていれば防げたな
スライスイテレータが個別のインデックスチェックコスト無しで境界チェックできるから

**デフォルトの名無しさん** · 2024/08/10(土) 12:59:11.84

Rustを使っていればってのは机上の空論なんだよな
自分でできないことを人に求めるなよと

**デフォルトの名無しさん** · 2024/08/10(土) 13:41:40.63

っぱRustだな

**デフォルトの名無しさん** · 2024/08/10(土) 13:42:02.22

今までそのプロジェクトに一度も貢献したことの無い人が「Rustで書き直さないの？」ってIssueを立てて即リジェクトされるのを見かける……
なぜかそういう人が好む言語 (彼らが本当にRustを書いているのかは不明)

**デフォルトの名無しさん** · 2024/08/10(土) 13:42:44.88

人間がチェックするよりコンパイラに機械的にチェックさせたほうがこういうミスは出ないってことだ

**デフォルトの名無しさん** · 2024/08/10(土) 13:45:07.25

>>92
今回のクラウドストライクのやらかしは本来はテストコードで見つかるはずの脆弱性なんだけどな

**デフォルトの名無しさん** · 2024/08/10(土) 13:56:12.38

Rustで防げる種類バグがあるのは事実でも、Rustに変えるとバグが減ります！と言っちゃうと嘘になる現実があるからみんな苦しんでるんですよ

**デフォルトの名無しさん** · 2024/08/10(土) 14:13:42.84

>>93
うっかりテストコードが抜けていても
Rustならコンパイラが撥ねてくれるからいいね

>>94
こういう参照バグやメモリ競合バグは確実に減るね

**デフォルトの名無しさん** · 2024/08/10(土) 15:13:38.79

それなのにRustは全然使われない理由って何なのかなあ

**デフォルトの名無しさん** · 2024/08/10(土) 15:33:50.34

クラウドストライクが件のセキュリティソフトを開発し始めた頃はまだRustが安定版になかったし仕方ない

**デフォルトの名無しさん** · 2024/08/10(土) 15:37:06.14

言語とビジネスは別の話だからだろ
顧客はソフトウェア製品にお金を出すのであって、「Rustで書かれていること」にお金を払うわけじゃない
既存プロジェクトを置き換えたところで顧客から追加のお金を貰えるわけではないし、置き換えをメインに作業してる間は機能追加などの開発は止まるわけだし
新規開発での採用は進んでると思うぞ

**デフォルトの名無しさん** · 2024/08/10(土) 16:01:23.31

以前からのは対策が遅れるの仕方ないよな
ただし新規案件でC++はアウトで言い訳できない
十分に学習とお試しする時間があったのだから

**デフォルトの名無しさん** · 2024/08/10(土) 16:03:24.43

もともとC++を使う案件自体が少ないんで

シビアなところは互換性を考慮してC++のまんまだし

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

>>99
お前は何様なんだよw

警備員[Lv.1][新芽] · 2024/08/10(土) 16:19:11.72

チンパンジーのあいちゃん

**デフォルトの名無しさん** · 2024/08/10(土) 16:58:24.77

>>82
trait 使うのやめて

>>77 の関数を
fn moge<F>(a: &str, b: &str, f: F) -> i64
where F: for<'a> Fn(&'a Hoge) -> Fuga<'_> {
中身
let m = f(hoge);
中身
}
にかえて

>>78 の呼ぶ側を
let x = moge(2, 5, |hoge| Fuga::from(hoge));
にしたらうまくいきました
ほんとうにありがとうございました

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

多分>>76の戻り値をFuga<'a>に直すのが根本的解決だけどうまくいったならもういっか

**デフォルトの名無しさん** · 2024/08/10(土) 22:48:05.26

タウリン好き
WinMacで動くクライアントアプリ書きたかってん

**デフォルトの名無しさん** · 2024/08/10(土) 23:49:33.16

>>104
私の記憶ではそこはやってみたのですが治りませんでしたね

**デフォルトの名無しさん** · 2024/08/11(日) 08:59:52.85

>>86 >>93 ほんそれ
こんなんテストしてれば見つかる話で恥ずかしいレベルの大チョンボ
マイクロソフトはもちろんクラウドストライクを訴えれば良いし
デルタ航空はマイクロソフトとクラウドストライクに5億ドル請求って言ってるけど
マイクロソフトを訴えるのは筋違いなので
デルタ航空以外の被害受けた各社はみんなでクラウドストライクを訴えれば良い

**デフォルトの名無しさん** · 2024/08/11(日) 11:53:58.67

Rustで防げるっていうのは、リストに正常にアクセスできたかチェックを強制されるって意味？

**デフォルトの名無しさん** · 2024/08/11(日) 12:32:03.37

標準環境なら範囲外アクセスはpanicして停止する
Cだとそこに有効なデータがあるものと思ってそのまま操作してしまい、その結果何が起きるか分からないということがある (言語でなくOS側のチェックにより防がれることはある)
no-std環境のRustについては自分も詳しくないので誰か書いてくれ

**デフォルトの名無しさん** · 2024/08/11(日) 12:55:28.88

>>108
Rustでは20個の領域を作った時点で
そこをその先頭アドレス=ポインタで指すのではなく
連続体(スライス)を抽象的な参照で指す
もちろんそのスライスへの参照は内部では先頭アドレスと長さになるが抽象的なスライス参照&[T]として扱う
そこからイテレータは20個の個別参照&Tを連続的に返したりインデックス指定によりget(index)でOption<&T>を得たりできる
21個目のアドレスを得たりその中身を見たりすることはsafeの範囲ではできない

警備員[Lv.4][新芽] · 2024/08/11(日) 14:07:38.05

それはどんなアセンブルコードに落ちているの？

**デフォルトの名無しさん** · 2024/08/11(日) 14:30:38.38

抽象的なレベルで安全を確保してしまえばその後にそのコードは最適化し放題
生成アセンブルコードはcargo asmでその場で確認できる

**デフォルトの名無しさん** · 2024/08/11(日) 15:19:18.37

>>111
範囲内かどうか比較する処理は入る。
ただし、静的に絶対安全と分かる状況なら最適化で消えることもある。
そうでなくても現代的 CPU だと分岐予測によって速度的ペナルティは小さいことが多い。
ゼロコストというわけではないが、 C 風のポインタがあまりにも素朴でミスしやすいことに対する解決法としては十分以上に小さいコストだと考えられている。
今では C++ にもスライス的な、範囲を表すクラスが標準に追加されていて再編成が進んでるのでやっぱりそのほうがよいという時代の潮流があるんだと思う。

**デフォルトの名無しさん** · 2024/08/11(日) 15:21:08.97

またいつもの嘘吐きが

**デフォルトの名無しさん** · 2024/08/11(日) 16:17:49.13

zigはリリースビルドだと範囲チェックをオフにしちゃうらしい
やっぱゼロコストじゃないよね

**デフォルトの名無しさん** · 2024/08/11(日) 16:42:50.50

>>111
例えばスライスをforで回してその値を書き込む関数
#[inline(never)]
fn foo(slice: &[i32]) {
　for t in slice {
　　write_volatile!(VOLATILE, *t);
　}
}

生成アセンブリコード
::foo:
　test rsi, rsi
　je .LBB11_3
　shl rsi, 2
　xor eax, eax
.LBB11_2:
　mov ecx, dword ptr [rdi + rax]
　mov dword ptr [rip + ::VOLATILE], ecx
　add rax, 4
　cmp rsi, rax
　jne .LBB11_2
.LBB11_3:
　ret

範囲内かどうかのチェックはC/C++と同じくループ内で1箇所のみで同じ動作になる

**デフォルトの名無しさん** · 2024/08/11(日) 17:01:54.96

ベアメタル環境でもRustってCより有用なものなの？
安全性は保証しやすくなるとして、書きやすさ (あるいは面倒臭さ) がどれほどのものか
実際経験ある人いる？

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

>>117
内部的には unsafe が必要だけど外に対しては安全性を保障している基礎的な語彙が標準ライブラリにはいっぱいあるじゃん。
ああいう感じの基礎的なものを環境に合わせて作るというのがスタートラインで、それが適切に出来てればベアメタル環境だからといって特別な違いはない。

unsafe を適切に下層レイヤに押し込めれていないと全体に unsafe が頻出して Rust の安全性の恩恵を受けにくいし、
安全性の恩恵を受けられないのに Rust の面倒くさい部分はあるという状況になって嬉しくない。

最初の整備をまじめにやるのがすごく大事。

警備員[Lv.7][芽] · 2024/08/11(日) 20:48:33.63

>>116
thx

**デフォルトの名無しさん** · 2024/08/11(日) 21:00:21.89

no_stdだとRustの基本的な機能は使えるけど
I/O入出力ライブラリなどが当然ないから
Hello, World!するのにこんな感じなのね
https://zenn.dev/zulinx86/articles/rust-nostd-101#final-code

**デフォルトの名無しさん** · 2024/08/12(月) 13:11:33.58

>>117
保守には良いと思う
リファクタリングには向いていない