Rust part20

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

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

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

**デフォルトの名無しさん** · 2023/06/10(土) 10:26:30.43

>>624
>>625
わざわざありがと
勉強になります

>>626
何ソレ?

**デフォルトの名無しさん** · 2023/06/10(土) 10:35:25.62

to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));

**デフォルトの名無しさん** · 2023/06/10(土) 15:12:50.25

テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい

**デフォルトの名無しさん** · 2023/06/10(土) 15:48:41.24

rusttypeとかab_glyphってのがダウンロード数多いみたい

**デフォルトの名無しさん** · 2023/06/12(月) 12:58:17.77

ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？

**デフォルトの名無しさん** · 2023/06/12(月) 13:04:11.65

？

**デフォルトの名無しさん** · 2023/06/12(月) 14:15:17.58

ちょっと何言ってるかわからない

**デフォルトの名無しさん** · 2023/06/12(月) 16:35:03.90

メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない

**デフォルトの名無しさん** · 2023/06/12(月) 16:47:01.05

メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。

**デフォルトの名無しさん** · 2023/06/12(月) 18:28:52.16

メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語

**デフォルトの名無しさん** · 2023/06/12(月) 18:44:13.30

そんな話一般論で語れる訳ないぞ
コードを出しな？

**デフォルトの名無しさん** · 2023/06/12(月) 20:02:49.65

>>636
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/12(月) 21:33:36.66

>>639
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。

**デフォルトの名無しさん** · 2023/06/12(月) 21:39:50.33

意味のない議論がほんと好きだねー

**デフォルトの名無しさん** · 2023/06/12(月) 21:44:05.58

コードが一切出てこないのが本当不思議

**デフォルトの名無しさん** · 2023/06/12(月) 21:45:00.87

>>640
Rustは実行効率を保ちながら安全性もある
Rustがやや不利でやや遅いと思い込んでいる具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/13(火) 11:32:39.43

>>639
>そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
ややどころか、大幅に遅くなるケースもあるぞ。
俺はこれ以上指摘しない。自分で分かるかどうかが技術力の試金石だ。

**デフォルトの名無しさん** · 2023/06/13(火) 11:35:33.48

また、
　「Rustは、どんな場合でも、効率を下げずに少数の関数の中に unsafe 箇所を閉じ込められる」
というのも嘘。

**デフォルトの名無しさん** · 2023/06/13(火) 11:43:16.69

ならお前はこれ以上指摘すんなよ未来に渡って

**デフォルトの名無しさん** · 2023/06/13(火) 11:53:41.84

>>644
デタラメ屋さんまた来たのか

**デフォルトの名無しさん** · 2023/06/13(火) 14:38:11.20

>>647
俺は一般プログラマより生まれつきだいぶ頭がいいので、通常のプログラマには
分からないのかも知れない。

**デフォルトの名無しさん** · 2023/06/13(火) 18:50:01.53

>>648
ぷw

**デフォルトの名無しさん** · 2023/06/13(火) 23:11:29.90

>>648
だいぶ頭良いプログラマーはこんなとこ来ねーからw

**デフォルトの名無しさん** · 2023/06/14(水) 17:49:14.80

可変長のバイナリデータを扱う場合の型ってやっぱvec<u8>あたり？
独自の型を定義する以外に他によさそうな型って何かあるかな

**デフォルトの名無しさん** · 2023/06/14(水) 20:22:43.85

>>651
Trait std::io::Readのrequired methodが
fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
であるように&[u8]でアクセスできれば何でもよい
そのうち可変で最もお手軽なのはVec<u8>
Trait std::io::Readのprovided methodの一つ
fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { ... }
もVec<u8>の可変参照を渡す仕様

**デフォルトの名無しさん** · 2023/06/14(水) 20:28:50.68

よくわからないんだけど
ライフタイムの例でよく出てくる関数の引数a,bを同じライフタイムの指定にするってやつは
どちらが選ばれるか分からないから使わないほうも長い方の寿命に合わせて残しておきますと言う解釈でいいの？

**デフォルトの名無しさん** · 2023/06/14(水) 20:57:15.56

>>653
その例となってる関数のコードくらいは書けよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:11:40.84

たぶんこういう例のことかな
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() >= s2.len() { s1 } else { s2 }
}
ここである呼び出しの時に
s1が'staticでs2が'x (!= 'static)だったとすると
'aとして寿命が短い'xの方が採用される
ただしこれはcovarianceである&Tの場合の話
invarianceである&mut Tの場合は逆になるので注意

**デフォルトの名無しさん** · 2023/06/14(水) 23:20:37.20

>>652
サンクス。やっぱvec<u8>が無難か
読みやすさだと構造体だけど要unsafeな上に
環境依存性も出ちゃうからな

**デフォルトの名無しさん** · 2023/06/14(水) 23:43:12.09

構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く

**デフォルトの名無しさん** · 2023/06/14(水) 23:49:13.19

データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね

**デフォルトの名無しさん** · 2023/06/14(水) 23:54:41.98

staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？

**デフォルトの名無しさん** · 2023/06/14(水) 23:58:17.85

もう何言ってんだよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:59:42.49

>>655
ライフタイムに関しては&も&mutもcovariantなので違いはありません

**デフォルトの名無しさん** · 2023/06/15(木) 00:08:38.46

Tに対して&Tはcovariant
Tに対して&mut Tはinvariant

**デフォルトの名無しさん** · 2023/06/15(木) 08:25:03.26

>>547
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>

**デフォルトの名無しさん** · 2023/06/15(木) 11:48:36.10

トヨタの車載OSってRUSTなんだ

**デフォルトの名無しさん** · 2023/06/15(木) 18:17:26.02

ライフタイムもtraitも難しすぎてマジでわからん

**デフォルトの名無しさん** · 2023/06/15(木) 18:21:52.25

ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな

**デフォルトの名無しさん** · 2023/06/15(木) 18:38:09.80

ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが

**デフォルトの名無しさん** · 2023/06/15(木) 18:40:44.72

自明なときに省略できるせいで理解しづらくなってる気はする

**デフォルトの名無しさん** · 2023/06/15(木) 18:44:18.80

日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状

**デフォルトの名無しさん** · 2023/06/15(木) 18:47:34.83

普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる

**デフォルトの名無しさん** · 2023/06/15(木) 18:52:46.39

と言う解釈なんだけど今のところ
普通に違ってるかもしれない

**デフォルトの名無しさん** · 2023/06/15(木) 18:57:24.57

OnceCellってようやく俺たちの欲しいものが来てくれたか
RefCellもCellも複雑なデータ構造作ると面倒だったからな

**デフォルトの名無しさん** · 2023/06/15(木) 20:40:26.65

Cellの種類が増えるってのは悪い兆候だね

**デフォルトの名無しさん** · 2023/06/15(木) 20:43:39.64

Cellを使ったら負け
他の言語からの移植だと、なぜか増えてしまう

**デフォルトの名無しさん** · 2023/06/15(木) 21:23:13.49

>>669
結構何を言ってるか分からないが引数のライフタイムを省略した場合は全部同じライフタイムを持つことになるよ

**デフォルトの名無しさん** · 2023/06/15(木) 21:54:27.47

>>669
main()→sub()→...と呼ばれている時に
'mainと'subをそれぞれの関数で持っている分の寿命とすると
寿命の長さは'static＞'main＞'subだが
「'sub以上の集合」⊃「'main以上の集合」⊃「'static以上の集合」なので
実は'staticの方がサブタイプ(下位)

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str において
寿命'aはジェネリックなパラメータなので
longest('main, 'static)と呼び出されれば'aは上位の'mainとなり
longest('main, 'sub)と呼び出されれば'aは上位の'subとなる

一方で
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'b str という関数だと
foo('main, 'static)と呼び出されれば'bはそのまま'staticとなり
foo('main, 'sub)と呼び出されれば'bはそのまま'subとなる
この場合はもちろん引数の短い方の寿命になるわけではない

fn bar<'a, 'b>(x: &'a str, y: &'b str) -> Bar<'a, 'b> という関数は
返り型が構造体(か何か)のBarでその内部に寿命'aのものと寿命'bのものを持つ
このように様々なケースがある

**デフォルトの名無しさん** · 2023/06/15(木) 22:01:26.73

>>672
OnceCellは前からあって広く使われていて今回stdに採り入れられた
once_cell::unsync::OnceCell が std::cell::OnceCell となった
staticで使われてきたSyncなOnceCellの方は別名となり
once_cell::sync::OnceCell が std::sync::OnceLock となった

**デフォルトの名無しさん** · 2023/06/15(木) 22:08:16.03

>>669
データフロー解析を知らないのだろうか?

**デフォルトの名無しさん** · 2023/06/15(木) 22:11:21.57

>>666
>コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
この”揃える”っていう感覚になる理由がこんがらがってる原因と見た

**デフォルトの名無しさん** · 2023/06/15(木) 22:12:42.39

>>674
負けではない
むしろCell類は内部可変性を与えてくれる便利で良いもの

>>673
性質の異なるものを使い分けられるから良いこと
コードの自由度や可読性も上がる

**デフォルトの名無しさん** · 2023/06/15(木) 22:15:38.46

>>676
上位下位にサブタイプにsubて嫌がらせか！

**デフォルトの名無しさん** · 2023/06/15(木) 22:39:43.11

>>675
まずこれは間違いだよね？
ライフタイムを省力すると全部別扱い

>>679
こんがらがってはいない
違うなら違う個所を訂正したらいいけど君には出来ないとみた

引数側のライフタイムは戻り値のライフタイムの検証のためのヒント

**デフォルトの名無しさん** · 2023/06/15(木) 23:12:41.78

>>682
こんがらがってないならまずは他人に理解できる日本語とコード例を書いてくれよ
間違いを指摘するとか以前に何を言いたいのかわからないんだって
俺だけじゃなくて何人も君が何を言いたいのか分からないって書いてるでしょ？

**デフォルトの名無しさん** · 2023/06/15(木) 23:29:09.39

>>682
>まずこれは間違いだよね？
>ライフタイムを省力すると全部別扱い
コンパイルエラーになるケースを含めて言えば「省略したら」全部別扱いは正しい
コンパイルエラーにならずに「省略できるのは」基本的に入出力で同じライフタイム扱いになる場合だから>>675の感覚もよくわかる
&と&mut違いで推論できる場合だけ例外

**デフォルトの名無しさん** · 2023/06/15(木) 23:59:14.48

>>682
ライフタイムの「仮引数」としては省略されると全部同じ扱いで合ってるよ。
https://doc.rust-lang.org/reference/lifetime-elision.html

一方で呼び出す側が認識しているライフタイムの「実引数」は違っていてもいい。
>>655の例で言えば、呼び出す側が x: &'b str と y: &'c str を渡して戻り値を z: &'d str に束縛するなら、'a は 'b: 'a, 'c: 'a, 'a: 'd を満たす最小のライフタイムに推論される。
そのような 'a があれば、&'b str <: &'a str etc. の部分型付け関係に基づいて、引数はすべて一度 &'a str にアップキャストされると思っていればいい。はず。
適切な 'a が無ければライフタイムに関するコンパイルエラーになる。
https://doc.rust-lang.org/reference/subtyping.html
https://rust-lang.github.io/rfcs/2094-nll.html

**デフォルトの名無しさん** · 2023/06/16(金) 00:20:26.24

Rustのコードが'まみれになるのはそういう理由だよね

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

>>685
＞　パラメーター内の省略された各ライフタイムは、別個のライフタイムパラメーターになります。

**デフォルトの名無しさん** · 2023/06/16(金) 00:30:18.44

>>685
いや、全部別になる
参照引き数が2つあれば'aと'b別になる

ソース
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference.
In other words,
a function with one parameter gets one lifetime parameter: fn foo<'a>(x: &'a i32);
a function with two parameters gets two separate lifetime parameters: fn foo<'a, 'b>(x: &'a i32, y: &'b i32);
and so on.

(snip)

Let’s look at another example, this time using the longest function that had no lifetime parameters
when we started working with it in Listing 10-20:

fn longest(x: &str, y: &str) -> &str {

Let’s apply the first rule: each parameter gets its own lifetime.
This time we have two parameters instead of one, so we have two lifetimes:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

このようにコンパイラは解釈する
そして戻り値が一意に決まらないのでコンパイルエラーとなる
そのためコンパイラは改善提案の一つとして全部同じにする提案コードを出す
fn longest<'a,>(x: &'a str, y: &'a str) -> &'a str {
全部同じ扱いと思い込んでいる人はこの提案をコンパイラが解釈したと逆に思ってしまったのではないか

**685** · 2023/06/16(金) 01:37:43.97

ほんまや申し訳ねえ
>>685はelisionのくだりは無視して明示した場合の話のつもりで読んでくだせえ

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

厳格な言語て嫌いでな
Verilogはなんの問題もなかったのに
VHDLはとうとう挫折した
てか予約後長いし,マクロがないのが許せなかったんだが
その意味でJavaも結局書く気にもならなんだわ

**デフォルトの名無しさん** · 2023/06/16(金) 14:09:49.37

>>675
だけど思い込みを書いてしまってごめん
勉強になりました

**デフォルトの名無しさん** · 2023/06/16(金) 14:58:22.19

水ノ都さんこんにちは

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

組み込み向けの解説記事でよさそうなのってない？
The Embedded Rust Bookは有名だけどSTM32ありきで書かれているしリンカとか肝心な部分の説明もないように見える
日本の人が書いているっぽいEmbedded Rust Techniquesの方がマシだがこれでも最低限か・・・

**デフォルトの名無しさん** · 2023/06/16(金) 18:25:34.38

>>693
The Book以外のドキュメントなら https://docs.rust-embedded.org/ からいろいろ探せるよ
あるいはEmbedded Rust Techniquesの人が書いてる「基礎から学ぶ組み込みRust」って本とか

**デフォルトの名無しさん** · 2023/06/16(金) 18:39:22.38

Rust好きがまあまあ見てそうなこのスレでもこのレベルなんだから一般に広まるのは無理ゲーだと思うわ

**デフォルトの名無しさん** · 2023/06/16(金) 19:23:08.87

問題点を具体的に言えずに曖昧に批判してるつもりの人がいるね

**デフォルトの名無しさん** · 2023/06/16(金) 19:40:36.76

自分でスレを読めばいい

お前の足りない脳を誰かがフォローしてボローチェックまでしてくれるなんて思うなよ

**デフォルトの名無しさん** · 2023/06/16(金) 19:42:26.19

言語の良し悪し以上にライブラリの分量が効いてくるんだわ。
そんでその大量にあるライブラリが利用しやすければなお良い。

やりたいことにマッチするライブラリがあるなら
自分で書かなくてよい部分が多くなるわけだし、
書く部分が少なければ少々の面倒くささなんてどうでもよくなる。

C や C++ の歴史の長さ故の物量に対抗するのは難しいけど
Rust は利用しやすさではかなり上回ってると思うので時間の問題だろ。

**デフォルトの名無しさん** · 2023/06/16(金) 23:38:46.36

>>695
単に5chがオワコンなだけだぞ

**デフォルトの名無しさん** · 2023/06/17(土) 20:33:46.40

>>683
ときにアセンブラで書必要に迫られる組込でRustあ日の目をみることなんてない

**デフォルトの名無しさん** · 2023/06/17(土) 21:26:17.31

>>694
その人は本を出していたのか。今度都内へ行ったときに見てみるか

**デフォルトの名無しさん** · 2023/06/17(土) 23:07:17.38

今日たまたま本屋で見かけた
売れるんかこれと思ったけど買う人がいる

**デフォルトの名無しさん** · 2023/06/18(日) 01:17:21.64

Rustでlinuxに機能を追加するならどんな機能が欲しい？みんな自由に言ってみて。

**デフォルトの名無しさん** · 2023/06/18(日) 09:07:15.46

>>695
ほんそれ

**デフォルトの名無しさん** · 2023/06/18(日) 09:08:49.10

>>698
crates.io はゴミだらけのイメージ(もちろんゴミじゃないのもあるがSN比が絶望的に悪い)

**デフォルトの名無しさん** · 2023/06/18(日) 09:13:33.05

>>703
これと言って無いし今のlinuxで満足(不満もあるけどそれがRustで解決するとも思わない)
カーネルもシェルもAPIもRust化しないと意味無くね？
どうせ unsafe! unsafe!! unsafe!!!

**デフォルトの名無しさん** · 2023/06/18(日) 09:15:13.52

>>705
まぁそれは何を比較するかじゃない？
ディストリビューション配布のCライブラリだと厳選されてるから当然クォリティ高いけど
GitHub上から探すとC系の方がS/N悪い（そもそもビルドできないとか）と感じるし

**デフォルトの名無しさん** · 2023/06/18(日) 10:10:46.67

rustは他の言語からの移植性が著しく悪い
移植と言うより最初から作ってるのと変わらない

**デフォルトの名無しさん** · 2023/06/18(日) 10:29:41.24

c　→　rustの移植が楽ならほおっておいても全部rustになる
その視点が欠けてる

ライナスがLinuxやGit作ったときのようにその他の勢力がおバカさんで実質アシストしてる時と同じような状況
Cust作るためのおぜん立てをしてるようにも見える

**デフォルトの名無しさん** · 2023/06/18(日) 10:37:34.85

後世から見たらライナスはlinuxとgitとcustを作った偉人ですと言うことになるんだろう

**デフォルトの名無しさん** · 2023/06/18(日) 12:12:13.93

仮にkernelや主要コマンドが全部rustに移植されたらその部分は安全にはなるわな
しかし現状そこまで行くかはわからん
なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
つまり主要なlibも全部rustで書き変えないとunsafeからは逃れられないけどものすごい作業量になりそう
いけるのかな？

**デフォルトの名無しさん** · 2023/06/18(日) 13:00:20.06

>>698
>Rust は利用しやすさではかなり上回ってると思うので
一部の需要に対してのみは、そういう傾向があるかもしれないとは思うが、
全般に対しては違う。

**デフォルトの名無しさん** · 2023/06/18(日) 13:12:59.30

>>700
Rustはインラインアセンブリが書けてRustの変数と連動できるため困ることはない
叩く前に勉強しよう

**デフォルトの名無しさん** · 2023/06/18(日) 13:26:34.81

>>712
個人的にRustはあれだけの実行速度、安全性の割にはかなり文法がシンプルで好きだけどね。

**デフォルトの名無しさん** · 2023/06/18(日) 14:02:54.81

>>714
蓼食う虫も好き好きだね。

**デフォルトの名無しさん** · 2023/06/18(日) 16:08:38.91

>>705
それ他の言語も同じだ
そういう宿命

>>708
だから安全なんだよ

**デフォルトの名無しさん** · 2023/06/18(日) 23:54:05.72

>>703
その発想からしてRustのパラダイムから逸脱しており反Rust

**デフォルトの名無しさん** · 2023/06/20(火) 17:00:50.46

>711
>なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
これ知るとRust安全神話なんて嘘八百八町なんよね
金儲けのために保守気取ってましたーに通じる

**デフォルトの名無しさん** · 2023/06/20(火) 19:31:43.67

>>718
こういう言説聞くと甘えにもほどがあるって思うけど、
そういう不満から Pure Java みたいに Pure Rust なライブラリが発展していけばいいね。

**デフォルトの名無しさん** · 2023/06/20(火) 19:54:19.85

unsafe=危険=意味なしみたいな人はRustを使うことが目的だと思っているんだろうね
安全なソフトウェアやシステムを開発することが目的ならそういう発想にはならないはずだ

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

純粋なRustのライブラリはまだ完成度が微妙なんだよな。PythonとかC,C++と比べると。勿論、他言語のバインディングのライブラリは結構豊富なんだけど、それだとRustを使う意義がないからな。

**デフォルトの名無しさん** · 2023/06/20(火) 20:20:14.97

>>718
部分的にでもマシになるなら意味あるやん。
論理的な破綻がないように定理証明器をベースにした言語とかもあるけど、
そのために既存のライブラリが使えないようだとそれこそ使い物にならんだろ。

結局はバランスおじさん「結局はバランス」

**デフォルトの名無しさん** · 2023/06/20(火) 20:41:02.57

>>718
それはunsafeとは何かを理解できていなくて初心者なのかも知れないけどかなりヤバイよ
ffiなんて例を出す必要はなくメモリ空間へのアクセスは最終的に生ポインタとなって当然unsafeになる

例えばslice[index]やslice.iter()の内部は当然unsafeな生ポインタを使って実装されている
ではunsafeで実装されているslice[index]やslice.iter()は危険か？となるがもちろん完全に安全だ
なぜならunsafeを内部に閉じ込めて安全なインタフェースを提供しているからである
これがRustの基本原理

ffiについても同様で例えばファイルのオープンや読み書きは通常OSへのシステムコールとなり通常ffiとなるため当然unsafe
しかしRustの標準ライブラリではそのunsafeを内部に閉じ込めて安全なインターフェイスとして提供している

このようにメモリアクセスもOS呼び出しもそれ自体は当然unsafeだがそれはモジュールの内部に閉じ込められている
そしてそれらを利用する側のプログラマーは安全なインターフェースのみを用いてsafeにプログラミングすることができる
そしてsafeな部分なコンパイラにより様々な安全性が自動的に保証されるという至上の恩恵をもたらすのがRust

**デフォルトの名無しさん** · 2023/06/20(火) 20:48:07.86

話の流れとは直接関係無いが、豆知識:
バグと言うものは、64BIT 整数を 32BIT 整数で受けたり、符号付きを符合なし
で受けたり(その逆でも)するだけでも起きるし、メモリ関連バグだけでは無い。

**デフォルトの名無しさん** · 2023/06/20(火) 20:50:12.42

例えば、OSの一度に行なえるファイル読み書きが10MBに制限
されている場合に、それを知らずにバイト数に20MBを指定して
しまったら、バグとなる。
テストでは10MBを超えるファイルを扱っていなかったら気付かない。

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

>>725
テスト仕様が10MB超えるファイルを扱うパターン記載されてないなら仕様じゃん

その場合仕様ミスではあるがバグとは呼ばない
バグってのは仕様通りに動いてない事を指すんやで

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

>>724
Rustは強い型安全性が保証されるためそれらのバグも起きない

>>725
それはプログラミング言語とは独立した無関係な話
制限があるのにエラーを返さないOSがあるならそれ自体の問題でありプログラミング言語は関係ない
エラーを返すならそのエラーの対処を正しくしていればバグは起きない