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/24(土) 08:21:40.08

>>382
grep

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

>>387
適切な抽象やデザインパターンと両立不可能な場合がある、ってマジ？
そんな話は聞いたことないな
具体的な例を教えて

**デフォルトの名無しさん** · 2024/08/24(土) 09:00:02.66

>>297
tauriがrustを基盤としたフレームワークなのだから
rustと特別な関係にあるservoに移行するのは必然では？

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

servoが最低限まともに動くようになるには、あと軽く5年はかかる
今のバージョン動かしてみ？
夢見すぎ

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

>>384
>unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う
こういうスタンスはダメだよな
作ってるアプリによっては許される場合もあるんだろうけど

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

>>390
俺はtauriのコアコンセプトはOSが提供するブラウザエンジンを使い、バイナリサイズやセキュリティアップデートの問題を解決することだと俺は思ってるんだ。
だからRust使ってるからservo使うってのは門外漢には自然に見えてもコアコンセプトを忘れてもともとの問題を解決しないOSSになっていってる感じがするんだよな。

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

ブラウザエンジンの選択肢が増えるだけでしょ
wryの中のfeatureが増えるのかwryごとservoに差し替えるfeatureになるのかは知らんけど

**デフォルトの名無しさん** · 2024/08/24(土) 12:27:15.89

.NET 9の新機能としてC#版Tauriが来るらしい
Go版Tauriもあるらしいし、流行ってるのかな

**デフォルトの名無しさん** · 2024/08/24(土) 12:33:53.63

疎結合でブラウザを GUI として使うには接続部分を上手く標準化する必要がある。
参加が多いほど標準化の圧力が生まれるし、良いことだと思う。

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

いまどき疎結合とか意味のないこだわりだな

**デフォルトの名無しさん** · 2024/08/24(土) 13:30:29.34

疎結合とかそういうかっこいい話じゃなくて
今どき新規にGUIツールキット作ってもウィジェット開発してくれる人が集まらないから
Web技術転用してしのぐかって話でしょ？

当のMicrosoftは3連続ぐらいで新GUIツールキットの開発に失敗しバグ残したまま撤退を繰り返してるし

**デフォルトの名無しさん** · 2024/08/24(土) 13:38:09.55

unicode の表示からしてウェブブラウザ以外は規格に追い付いてない感触はあるなあ……

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:07.91

>>393
そう思うならforkすればいいのに
オープンソースなんだし
コード書かない人には一家言もない世界よ

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:41.99

いまはネットワークが高速で繋がっている前提なのなw

**デフォルトの名無しさん** · 2024/08/24(土) 13:54:50.23

>>395
仕組みは組み込みWebViewをネイティブの上で起動してるだけだから作るのが大して手間じゃないし実装してみたって感じでしょ

**デフォルトの名無しさん** · 2024/08/24(土) 14:58:54.54

>>382
github

**デフォルトの名無しさん** · 2024/08/24(土) 15:01:04.10

>>387
＋１

**デフォルトの名無しさん** · 2024/08/24(土) 15:03:55.41

>>401
これホント困るわ

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

>>400
いや、牛丼屋なのに鰻丼を中心にするんだ…みたいな気持ちがあるだけで、俺は現状 tauri に用はないので…。

ちゃんと使ってる crate はコントリビュートチャンスを伺ってるよ。

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

unsafeブロックってどこからどこまで囲えば良いんだろう

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

>>407
「可能な限り小さく」が原則

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

Rustでunsafeは使ってはいけない
例外的にunsafeの使用が認められるのは以下2点のみ
ベテランが基盤クレートを提供する時
ベテランがFFI部分を記述する時

**デフォルトの名無しさん** · 2024/08/24(土) 18:20:35.25

unsafe なことをやっている箇所をなるべく小さい範囲で囲むべきだがお互いに関係のある複数の unsafe がごく近くにあるならまとめて囲むほうが分かりやすいということはあるかもね。

**デフォルトの名無しさん** · 2024/08/24(土) 18:29:15.33

そういうケースを除くとunsafeを使ってる者は技術力がないだけのバカと
パフォーマンスにほとんど変化しないのに高速化してるつもりで保守性を下げてるアホだからな

**デフォルトの名無しさん** · 2024/08/24(土) 18:32:37.91

Rustでどう書くのか分かりませんが、C言語で書けば、
BYTE *ConvertUintToPtr( Uint32 u ) {
　unsafe {
　　return (BYTE*)u;
　}
}
のような関数をRustで作ることは出来ますかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:33:08.29

>>408
最小限にするなら、>>380はこうしたほうがいいってことかね
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27cd2a3b6b850770a839c17d6fe3ec4

unsafeブロックもブロックではあるから、通常のブロックと同様にdropが働くから、それに注意して無効な参照をsafe内に持ち出さないようにすればいいってことかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:43:12.73

>>406
現状だと
servo「うちの鰻丼を置かせてください！」
tauri「まぁ客に出せる味になったらメニューに加えてもいいよ」
くらいの温度感に見えるけどなぁ。これまでの発表はservo側からだし、tauriチームとしてservoに全面移行するなんて話は出てないと思うけど

**デフォルトの名無しさん** · 2024/08/24(土) 18:46:57.91

>>413
unsafeの作法も知らない雑魚はunsafe Rustを使うな
基礎から学んで出直してこい

**デフォルトの名無しさん** · 2024/08/24(土) 18:51:25.05

unsafe Rust使うくらいならCでよくない？
反対意見あったら言ってくれ

**デフォルトの名無しさん** · 2024/08/24(土) 18:52:59.44

>>412
当然できるけど
危険な行為なので熟練者とキチガイしか使わないよ

**デフォルトの名無しさん** · 2024/08/24(土) 18:53:02.17

>>415
一応Referenceのunsafe blockの部分は読んだけど、nomiconも全部読まなきゃだめ？
具体的にどこが間違っている/作法に反しているのか指摘してくれるとありがたいんですが……

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:23.20

>>417
参考のため、どう書けばいいのか教えていただければ幸いです。

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:51.72

>>416
反対意見なんてないよ
人間はバカだからC/C++ではなくRustを使わざるを得ない状況になってるんだし
なるべくならRustなんて使いたくもない

**デフォルトの名無しさん** · 2024/08/24(土) 18:57:28.86

>>416
インフラやFFI部分のライブラリを作る上級者は例外として
unsafeを使うのはキチガイばかりだね

**デフォルトの名無しさん** · 2024/08/24(土) 19:07:44.35

>>412
変換するだけならunsafeも特に要らなくて、ただのasキャストでいいみたいね
fn convert_uint_to_ptr(u: usize) -> *mut u8 {
u as *mut u8
}

これをやるだけの関数なら、まだstableじゃないけど標準ライブラリにもあるようで
安全にするためにstrict provenance rulesなる仕様を検討中な様子
https://doc.rust-lang.org/std/primitive.pointer.html#method.from_bits-1
https://doc.rust-lang.org/std/ptr/fn.with_exposed_provenance_mut.html

**デフォルトの名無しさん** · 2024/08/24(土) 19:24:20.93

ポインタは観測するまで安全

**デフォルトの名無しさん** · 2024/08/24(土) 20:06:41.28

逆参照しなきゃ安全
だけど大体はアドレスがわかってるならそれを指すポインタや参照もわかってるはずなのでアドレスをポインタにする機会はそんなにない

**デフォルトの名無しさん** · 2024/08/24(土) 20:08:48.83

>>392
そらそうやけど、それでうまく行くならC++でええやんいう話になるわな

**デフォルトの名無しさん** · 2024/08/24(土) 20:22:17.51

Rustに不慣れで技術力の低い人がunsafeを使う傾向が高い
ほとんどのケースは既存の安全なパーツを組み合わせるだけで安全に実装できる

**デフォルトの名無しさん** · 2024/08/24(土) 21:14:33.88

>>426
単発君
自分でunsafeを書く必要性がない書く気がないならそれでいいと思うし、その立場は理解したから、どうか他人の足を引っ張らないでくれ
unsafeの書き方を学ぼうという同志がいないのならそのうち去るから、すまないがそれまで待ってくれないか

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:04.07

unsafe で UB になる場合を知りたい場合にはどこに仕様が書いてあるのかがそもそもわからん。

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:45.92

UnsafeCellを使ってる頭のおかしな人のコードはborrow checkerに引っかかってコンパイルを通せないところから始まってるよね
unsafeの使い方を学ぶのではなくsafe Rustの使い方を学ぶべきかと

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

>>428
現状のベストエフォートのまとめはこれですかねえ
LLVMのマニュアルなんて参照しちゃってるから、LLVM IRまでのloweringの詳細を完璧に把握でもしていない限りこれを一次資料として参考にするってのは無理そうですが……
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

あとは呼んでいるunsafe fn/実装しているunsafe traitのドキュメント（当たり前）と、the Referenceをundefinedで検索した結果とかでいいんでしょうか

**デフォルトの名無しさん** · 2024/08/24(土) 22:14:58.07

既存の安全なパーツを使いこなせる熟練者であることがunsafeを書くための最低限の資格だ
これができないとunsafeを使うべきか否かという入口すら判断できない

**デフォルトの名無しさん** · 2024/08/24(土) 22:53:26.45

Rust のメモリまわりの動作モデルは結局は C/C++ に合わせることにしたみたいな話をどこかで見たようなおぼろげな記憶がちょっとある。
LLVM がなんだかんだで C/C++ を想定した形になってしまっているのとその辺の低レイヤの部分がちゃんとモデル化されている言語が C/C++ くらいしかないから Rust のためにあらためて検討するくらいならもう合わせちゃって良くない？みたいなニュアンスだったと思うんだけどどこで見たのかも思い出せないから違ってたらごめんね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:22:54.73

>>422
有難うございます。
ところで、Rustでは、unsafe 以外では、専ら参照型が使われると思っていたのですが、
unsafe を使わない部分でも、ポインタ型 * が使えるようですね。
Rustにおけるポインタ型を参照型のアドレスに採用する方法も教えていただければ幸いです。
C++ であれば、
T x;　//xは、T型の変数。
T *p = &x;　//pは、T型へのポインタ型。アドレスは変数xのアドレス。
T &r = *p;　//rは、T型の参照型。
で、参照型rのアドレスがpの指すアドレスに一致しますね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:31:10.68

>>433
生ポの参照外しはできない
生ポを参照にすることもできない
それらはunsafe

**デフォルトの名無しさん** · 2024/08/24(土) 23:50:29.93

>>434
では、C++であるならば、以下の様に書けそうなコードをRustで書くとすると
どうなるでしょうか。
BYTE &ConvertPtrToRef( BYTE *p ) {
　unsafe {
　　return *p;
　}
}

**デフォルトの名無しさん** · 2024/08/25(日) 00:56:39.20

unsafe { p.as_ref().expect("p is not null") }
unsafe { p.as_mut().expect("p is not null") }
unsafe { &*p }
unsafe { &mut *p }

**デフォルトの名無しさん** · 2024/08/25(日) 01:28:05.04

そもそもRustの参照とC++の参照が1対1に対応しないので、そこを無視してもどうなんだという問題

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/25(日) 06:34:29.42

>>438
まじか

**デフォルトの名無しさん** · 2024/08/25(日) 15:06:59.24

>>433
std::slice::from_raw_parts
std::slice::from_raw_parts_mut

**デフォルトの名無しさん** · 2024/08/25(日) 16:07:14.33

unsafe大好き

**デフォルトの名無しさん** · 2024/08/26(月) 07:21:14.48

unsafe rustよりzig

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

zigは未完成

**デフォルトの名無しさん** · 2024/08/26(月) 11:03:43.55

zigよりNim

**デフォルトの名無しさん** · 2024/08/26(月) 12:45:51.89

Rustでunsafeを迂闊に使っていると信用失墜リスクがある
例えば安全に書けるシーンでunsafeを使っていればRustに疎くレベルが低いと客観的に判定されてしまう
そして書いたコードは信頼されなくなるため要注意だ

**デフォルトの名無しさん** · 2024/08/26(月) 13:27:24.67

んでNimよりCってわけ

**デフォルトの名無しさん** · 2024/08/26(月) 23:59:19.70

unsafeなしに拘るならそもそもunsafeという仕様のない言語を使えば良いのでは

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

unsafeはFFI部分と基盤ライブラリで必須
そのためにある

**デフォルトの名無しさん** · 2024/08/27(火) 01:18:15.13

あんまり必死になると>>307が図星なのがバレるぞ

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/27(火) 05:12:31.56

>>450
既に貰ってる

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:24.38

unsafeって危険だから描くんじゃなくて
unsafeを描くことで危険を回避出来るんだ
だからunsafeが使われてるからって危険なコードじゃないんだ
unsafeを観たら危険だと脊髄反射する方が馬鹿の誤解

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:59.31

だから >>445 はピンぼけ的外れ

**デフォルトの名無しさん** · 2024/08/27(火) 14:29:34.76

RustかC++のどちらかなのかはRustで落ち着いたけど
unsafe RustかCかは結局どっちがいいんだい？

**デフォルトの名無しさん** · 2024/08/27(火) 14:38:55.67

>>454
え？いつの間に落ち着いたの？

**デフォルトの名無しさん** · 2024/08/27(火) 14:47:28.58

>>454
Zigだよ
ZigこそがベターCで、C++風味が入っていない

**デフォルトの名無しさん** · 2024/08/27(火) 15:35:17.48

>>452
おまえは何を言ってるんだｗ

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

>>456
1.0になってから来てくれ

**デフォルトの名無しさん** · 2024/08/27(火) 16:13:13.47

>>454
最大サイズのマインスイーパーを30分かけてじっくり解きたい → C
マインスイーパーは最小でいいから余った時間でソリティアやりたい → (unsafe) Rust
作業に戻る → C++

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

最大サイズのマインスイーパーだと
プログラムに解かせるのに30分くらいかかるのか
それはメモリを積むと速くなったり
コア数を積むと速くなったり
未知のアルゴリズムで速くなったりする？

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

まあそうなるよなw
頭悪いたとえ話だから仕方がない

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

でもプログラムに解かせるのに30分もかからないだろくらいの感覚は常識として持っておいて欲しいところ

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

マインスイーパーはNP完全であると証明されていてかなり難問
さらにそもそも常に論理的に解けるわけではないためリゾルバーは勝率100%ではなく問題難易度別に平均勝率が示される
具体的には論理的推論で開けられる場所がなくなった時に人間は運ゲーとなるが機雷のある場所の確率計算により勝率を高められる
その手法ならびに巨大サイズによっては計算時間30分はありうるのではないか

**デフォルトの名無しさん** · 2024/08/28(水) 11:57:33.04

>>460
そんな訳無い
10秒もかからん

**デフォルトの名無しさん** · 2024/08/28(水) 12:03:45.27

例えば話悪すぎるのは理解するけど、プログラムにマインスイーパー解かせる話だっけ

**デフォルトの名無しさん** · 2024/08/28(水) 12:21:33.97

>>464
なぜ0.1秒ではなく1秒ではなく100秒ではなく10秒なのか？

**デフォルトの名無しさん** · 2024/08/28(水) 12:23:32.67

>>465
プログラム板のプログラミング言語スレでそれ以外にどんな可能性があるか？

**デフォルトの名無しさん** · 2024/08/28(水) 13:59:37.19

誤魔化せれば何でもいいから意味の無いレスを拾ってごちゃごちゃ書き込んでるんだろう

**デフォルトの名無しさん** · 2024/08/28(水) 16:33:13.07

いつのまにかAndroid公式ドキュメントにRustの章ができてた

**デフォルトの名無しさん** · 2024/08/28(水) 17:22:14.56

AndroidはJNIをJavaとバイナリとの間に噛ませないといけないからほんとに面倒くさい

**デフォルトの名無しさん** · 2024/08/28(水) 19:34:23.32

>>459
君頭悪いのに無理に例えなんか使わないほうがいいよ

**デフォルトの名無しさん** · 2024/08/28(水) 21:16:27.54

まさかマインスイーパーの例え自体が地雷になるとはｗ
Rustスレなのにunsafeだな

**デフォルトの名無しさん** · 2024/08/28(水) 22:54:19.83

さあみなさま、脱unsafeを心がけていきましょう！

**デフォルトの名無しさん** · 2024/08/28(水) 23:16:33.26

>>456
Zig、エリアアローケーターがとても魅力的なんだけど、非同期まわりの仕様が白紙に戻っちゃったのがなあ
もちろんZigの求められている役割的に非同期はそこまで重要ではないのだけれどちょっと悲しさを感じる
なんでもZigに限らずLLVMとasync/awaitの相性がとてつもなく悪いらしい
https://www.reddit.com/r/Zig/comments/1d66gtp/state_of_async_in_zig/
長文すまん

**デフォルトの名無しさん** · 2024/08/28(水) 23:17:49.58

Swiftのasync/await良く出来てるけど？

**デフォルトの名無しさん** · 2024/08/28(水) 23:25:03.26

>>475
加えてGolangやKotlinのasync/awaitもよく出来てる
成功例はあるんだしきっとなんとかしてくれるよね

**デフォルトの名無しさん** · 2024/08/28(水) 23:30:17.85

golangはasync/awaitじゃなくてCSPな？

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

>>477
すまん指摘助かる

**デフォルトの名無しさん** · 2024/08/28(水) 23:41:09.49

>>474
気になったけどエリアアロケータはarena allocatorの空目？
arenaはアリーナ（闘技場）

**デフォルトの名無しさん** · 2024/08/28(水) 23:41:42.12

GoもKotlinもLLVMバックエンドじゃないだろ

**デフォルトの名無しさん** · 2024/08/28(水) 23:46:05.67

>>474
読んでみたが登場人物たちが無知すぎるな
特にZigでのasync/awaitの経緯を解説しているmlugg0はRustについて不慣れで全くわからないと答えてる

>>Zigに限らずLLVMとasync/awaitの相性がとてつもなく悪いらしい

それは間違いでLLVM coroutineを使おうとすると重くなる
Rustはそれを使わずにスタックレスなステートマシンとして実現しているため軽く良く出来ている

**デフォルトの名無しさん** · 2024/08/29(木) 01:22:47.24

>>481
Rustは最強ってことでいいけどここにいてもお前がザコなのは変わらないからもう引っ込んでなよ

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

>>480
バカなAIが跋扈してる

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

Zigは技術的な敗北でasync/awaitを削除しただけでなく思想的にも嫌悪や不要論が跋扈していて終わってるな

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

>>474
スレッドプール作れるし問題なし

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

async awaitが何なのか理解していない人たちがZigに集まっている

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

Zigは未使用変数がエラーになるのがな…
せめてデバッグビルド中はワーニングになってほしいが
作者の思想的に無理そうなんだよな