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(土) 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は未使用変数がエラーになるのがな…
せめてデバッグビルド中はワーニングになってほしいが
作者の思想的に無理そうなんだよな

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

>>487
Cとかでよくある消すと何故か動かなくなる未使用変数を撲滅する対策とか？
もしそうならまっとうに境界チェックしてほしいが。

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

zigはビルドツールのccとしてcmakeより使いやすくて好き

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

>>488
いや、Rustと同じく変数名に_つければ通るからあんま関係ないかな
これのせいで実装中やデバッグ中に関数呼び出し一つコメントアウトするたびに
あちこちに_をつけてまわらないといけないからかなりつらい

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

Zigは未完成のまま終わりそうだな

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

>>489
pkg-config 呼び出す機能がないんじゃない？

**デフォルトの名無しさん** · 2024/08/29(木) 09:33:53.27

>>490
これだけ変数の使用不使用にうざい仕様の割に
同一scope内での二重定義(上書き)はあっさりと許す糞仕様ω

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

シャドウイングがない言語は不便すぎるから有るのは正しい

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

>>486
async awaitをやさしく解説してください

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

せんでええよ

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

https://rust-lang.github.io/unsafe-code-guidelines/introduction.html
こんなのあるんだ、まだ中身スッカスカだけど

**デフォルトの名無しさん** · 2024/08/29(木) 14:09:44.24

async (∩ﾟдﾟ)ｱｰｱｰ
await 聴こえなーいΩ＼ζ°)ﾁｰﾝ

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

asyncの一番難しいとこは発音だな
間違えてる日本人が多い

**デフォルトの名無しさん** · 2024/08/29(木) 14:49:29.45

>>497
それは「まだ」じゃなく
すでに捨てられた後のもの

**デフォルトの名無しさん** · 2024/08/29(木) 19:49:23.69

Rustの非同期が非常に軽く上手くいってる理由は簡素であることかな
futureの構築とfutureの実行が明確に分離されている
構築で返されるのは単なる構造体の値でありヒープ利用を前提としない
実行はポーリングしないと何も進まない簡素さ
asyncタスクはステートマシンによるコルーチンとして実装されている
つまり個別のスタックを必要とせずに動くためメモリリソースの点でも有利となってるね

**デフォルトの名無しさん** · 2024/08/29(木) 23:02:59.56

>>479
エリアとかって恥ずかしい奴と思ってた。

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

>>489
cmakeのバージョン変化に嫌気して素のgnu makeに戻ったわ。

**デフォルトの名無しさん** · 2024/08/29(木) 23:20:35.98

>>502
area allocatorで検索したらarena allocatorしか出てこなかった
どっちが正解か分からんけど勘違いしたままだとプレゼンで恥かきそう

**デフォルトの名無しさん** · 2024/08/30(金) 01:16:51.32

https://en.wikipedia.org/wiki/Region-based_memory_management
region, zone, arena, areaと呼ばれると書いてあるし言うほど間違いじゃないんじゃね

むしろ”闘技場”に驚いたわ

**デフォルトの名無しさん** · 2024/08/30(金) 01:40:41.30

両方あるんか
arenaは知ってたけどareaでも意味通じるから迷ってた

**デフォルトの名無しさん** · 2024/08/30(金) 02:21:05.28

areaだと一般用語の～エリアと曖昧になりやすいせいかarenaと呼ばれることが多いかな
特にRustではその手の各種クレートはxxx-arenaと名付けられているね
そのため「そこはアリーナ系を使おう」だけで話が通じると思う

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

Rustで勘違い3選
https://qiita.com/namn1125/items/2a59f486cce30fd2b889

**デフォルトの名無しさん** · 2024/08/30(金) 14:03:33.10

高階トレイト教会

**デフォルトの名無しさん** · 2024/08/30(金) 18:16:40.82

https://japan.zdnet.com/article/35223295/2/
> LinuxへのRust言語の導入の話になると、Torvalds氏は採用のペースが上がらないことに失望感を示した。
> 「更新が思ったほど速く進んでいないが、問題の一端は、昔からのカーネル開発者が『C』に慣れていて、Rustを知らないことにある。彼らは、ある面で大きく異なる新しい言語を学ばなければならないことを、あまり歓迎していない。そのため、Rustに関しては多少の反発がある」

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

まあ既存のエンジニアにRust学ばせるんじゃなくRustやりたいってヤツが実績積んで参加すべきだわな

**デフォルトの名無しさん** · 2024/08/30(金) 18:22:28.02

昔ながらのカーネル開発者は賢いからCで良いんだよな

新参のCまともに書けないバカがカーネルにいっちょ噛みするためにRust推してみたけど、本人はRustわかる程度の知能はあるがカーネル理解できる程の知能はないからカーネル周り書けず、他人にRust勉強しろと喚くことしか出来ない

**デフォルトの名無しさん** · 2024/08/30(金) 18:27:03.74

C++の苦痛を経験しないと有難みがわからないのがRustだからな。linuxカーネルがC++を採用していたらすんなり移行してたかも

**デフォルトの名無しさん** · 2024/08/30(金) 18:42:19.31

C++なんてバグの温床だから採用しないのは正解

**デフォルトの名無しさん** · 2024/08/30(金) 19:05:19.61

>昔ながらのカーネル開発者は賢いからCで良い

＋1

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

>linuxカーネルがC++を採用していたらすんなり移行

これは絶対無い
むしろC**使われてるとRust化から遠ざかる
断言出来る
RustとC++の相性は最悪