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/19(月) 23:57:37.03

>>316
unsafeばっかりになる、が妄想思い込み

**デフォルトの名無しさん** · 2024/08/20(火) 09:21:19.12

変なことやることになった時にはRustのアロケーター指定面倒でZigはその辺楽だなってなる

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

同一言語内で失敗例と成功例があるのは客観的事実だから
「言語を変えたら成功した」という因果関係は妄想と言われても仕方ない

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

>>317
理想的に設計できればいいけど現実はそうではない。
ホスト環境ありの高レイヤで unsafe まみれにならないのは標準ライブラリが慎重に設計されてるからで、標準の設計と同じくらいに上手くやれる人は稀。
そりゃカスなプログラマだからだろって言われればそのとおりだがだいたいの現場はカスなもんなんだよ。

**デフォルトの名無しさん** · 2024/08/20(火) 12:23:22.63

標準ライブラリのunsafeノウハウて、まとまっていたっけ？

**デフォルトの名無しさん** · 2024/08/20(火) 14:02:00.57

うまくまとまってしまうとunsafeじゃなくても良くなる

**デフォルトの名無しさん** · 2024/08/20(火) 17:21:26.26

unsafeまみれにならないのは、Rustが苦手な良いアルゴリズムを知らない人。
そういう人が圧倒的に多いので多数派意見になっているだけ。

**デフォルトの名無しさん** · 2024/08/20(火) 18:19:19.40

unsafeまみれにならないように工夫すれば、unsafeまみれにならない
だからこそ、unsafeまみれにならないように工夫すべきである、と私は思いますね

**デフォルトの名無しさん** · 2024/08/20(火) 18:55:32.33

CやZigで作ったあとにAIで安心安全なRustに変換でいいんじゃね？
あ、それだとRust必要ないかも

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

いうてRustはまだまだ発展途上でしょ。このケースはunsafeなしでも安全性を推論可能でコンパイルできる。みたいなケースは今後もどんどん増えていくんじゃないの？

**デフォルトの名無しさん** · 2024/08/20(火) 21:23:27.30

実際unsafeの安全性を証明するための研究も結構行われてるしな
Cみたいになんでもありだとかなり厳しいけど
Rustならunsafeといってもそれなりに制約があって研究としてもやりやすいらしい

**デフォルトの名無しさん** · 2024/08/20(火) 21:28:14.77

こゆことなんよ
https://x.com/atalocke/status/1599076649341194242

Zig is the new C.

Rust is the new C++.

Go is the new Java.

WASM is the new JS.

**デフォルトの名無しさん** · 2024/08/20(火) 21:53:19.45

>>325
変換して生成させるかゼロから指示して生成させるかどちらが効率的かは意見が分かれるが、

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

一般的にAIに生成させる場合は少なくとも以下の3つが必須とされる
(1) AIが安全なコードを生成できること
(2) 生成物の安全性を人間が確認できること
(3) 安全性とは別にAIのミスや暴走を食い止めるため人間がレビュー確認できること

**デフォルトの名無しさん** · 2024/08/20(火) 21:55:11.06

(1)は生成AIにとってかなり難しく様々な安全なパターンの学習をさせても間違いが起きるうる
生成先がRustならばコンパイルが通る条件など指定で間違いを防げる
(2)も生成先がC/C++やマシン語だと難関だがRustならばコンパイラに任せられる
(3)は(1)(2)によりRustを読める人材が今後も必要になることを意味する
さらに核心部分はAIに任せず人間が書くことで対AIの安全性を確保する考え方もある
したがってRustを書ける人材も必要とされる

**デフォルトの名無しさん** · 2024/08/20(火) 22:02:42.33

生成AIは既存物の変換処理は苦手でしょ
自然言語処理でやれないの？

**デフォルトの名無しさん** · 2024/08/20(火) 22:26:06.21

>>325のようにCで書いてAIにRustへ変換させることが出来るようになったと仮定しても
Rustを直接書いて開発できる人と比べて不利と思われる
さらに保守性の面では二重管理となってしまう

**デフォルトの名無しさん** · 2024/08/20(火) 22:41:15.58

すでにCで書かれてるものをRustで書きなおすのが時間と人材の無駄なのであって、イチから作るのであればRustでいいのでは…？

**デフォルトの名無しさん** · 2024/08/20(火) 22:46:48.76

>>323
[補足]
「Rustでは上手く書けないアルゴリズム」を知らない人は、そもそも、
unsafeまみれにならない、ということが言いたかった。
「Rustでは上手く書けないアルゴリズム」を知らない人が圧倒的に多いので多数派意見になっている。

**デフォルトの名無しさん** · 2024/08/20(火) 22:49:18.72

>>335
[さらに補足]
・C言語は、どんなアルゴリズムでも(分け隔てなく効率良く)書ける。
・Rustは、unsafeの範囲内のでは限られたアルゴリズムだけが効率よく書け、
　それ以外のアルゴリズムは、効率が落ちてしまう。

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

CPUから見たメモリは何でも自由にできるunsafeな存在だからさ
一番下ではunsafeな操作が必須な存在となることは当たり前さ
そのためunsafeだらけのRust標準ライブラリがそこをカバーしているのさ
だから普通のプログラマーはunsafeを使わずにプログラミングできるのさ

**デフォルトの名無しさん** · 2024/08/21(水) 00:04:15.03

過去一キショい語尾のキャラ作り

**デフォルトの名無しさん** · 2024/08/21(水) 03:19:43.62

>>336
最初からそう言えば良いのにωωω=2πf

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

>>336
Cで安全に書けるならば
Rustでもそれをライブラリとして提供できる
利用者にとってその中身がunsafeかどうかは気にする必要がない
例えばRustの標準ライブラリは何千ものunsafeブロックが含まれている

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

>>339
Rust は清書用(キリっ

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

>>340
>Cで安全に書けるならば
>Rustでもそれをライブラリとして提供できる
問題は本当にCで安全に書けているのかわからないところ
アルゴリズム系は安全性がそれなりに担保されているからsafeラッパーを提供するのは難しくない
難しいのはFFI

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

このスレにはRust理解してないガイジしかおらん

**デフォルトの名無しさん** · 2024/08/21(水) 18:51:27.99

オレはコンシューマ寄りであまり理解せずにRust書いてる
ほとんどSQL文のWEB APIだけど

**デフォルトの名無しさん** · 2024/08/21(水) 19:17:17.31

サーバーやクラウドでCPUとメモリの使用リソース節約のために参照とライフタイム使いまくるプログラミングもあれば
リソースは金をかければよいだけだからとヒープ使いまくりのお大尽プログラミングもある
後者は技術力が低くてもいける

**デフォルトの名無しさん** · 2024/08/21(水) 20:29:33.23

有能な技術者を揃えて手間もかけて倍の性能を出すよりは機械を二台にするほうがコスト安ってのが昔の考え方だったんだよ。
高いのは設備より人の時間だったの。
いわゆる富豪的プログラミングという概念が生まれたのもそのときはちゃんと合理的な話だった。
だけど今は設備投資した上でまだ性能が要るという段階までコスト・性能の要求が厳しくなってきて揺り戻しが起こってる。

**デフォルトの名無しさん** · 2024/08/21(水) 22:37:24.76

Rustでライフタイム付きの構造体を書いたことがなく書けない人とかな
Cでポインタを含む構造体を扱うより楽なのに

**デフォルトの名無しさん** · 2024/08/22(木) 00:18:39.99

同意

**デフォルトの名無しさん** · 2024/08/22(木) 00:33:56.97

そういう話ではないと思うけど、既存のC/C++のコードで構造体がポインタや参照 (C++のみ) を持ってた場合、それをRustに移植しようとすると面倒なケースはあるよね
元の設計でも参照先よりも自身の寿命が短いならライフタイム注釈を付けられるけど、そうでなければunsafeとポインタにするか Rc などに置き換えるかになる？

**デフォルトの名無しさん** · 2024/08/22(木) 00:54:54.13

>>349
指してる先の寿命が短い危険なC/C++コードが
複雑で巧妙な条件管理でぎりぎりダングリングポインタとなることを上手く避けている
ように見えて実はある条件が揃った場合にはアウト、とかな

つまりunsafeでそのまま移植するとそのまま致命的バグが残ってしまう
根本から設計しなおせないならばRcと弱参照で致命的バグ回避か

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

今、FirefoxとChromeってどっちがRust率高いんだろ？

JSONパーサーがC++からRustになった「Google Chrome 128」、ゼロデイ脆弱性の修正も
https://forest.watch.impress.co.jp/docs/news/1617607.html

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

>>351
ChromiumとChromeのC++メモリ脆弱性が日常茶飯事になってるから
少しずつRustへ置き換えていく方針なのか

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

Firefoxはおっさんしか使っていない

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

chrome 系一色になるのも良くはないからね。

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

Rust信者からするとこの期に及んでC++でブラウザの再実装なんて始めやがったLadybirdのことは全力で呪ってる感じ？

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

chromiumがC++のメモリ管理ミスでセキュリティ脆弱性を毎回出し続けているように
ブラウザのような新機能を常に加えていく大規模ソフトウェアでC++の使用は無理がある
だからchromiumはRustを採用し始めた

**デフォルトの名無しさん** · 2024/08/22(木) 23:59:43.53

>>355
Ladybirdは作者が慣れてるから初期実装をC++でやっただけでSwift6.0が出たら移行みたいだよ
まぁRustのエコシステムに貢献してくれたほうが良かったとは思うけど、Swiftならいいんじゃないかな

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

Swiftが遅い原因は
Rustで例えるとArc<Mutex<T>>を常用することでメモリ管理問題から逃げているため
という理解でいいのかな

**デフォルトの名無しさん** · 2024/08/23(金) 00:24:23.39

Chromeは生ポインタ使ってるところを
一気にスマートポインタ等に置き換えたという
話を何年か前に聞いたけどそれじゃダメなんだな

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

&strはlowercaseﾌﾟﾙﾌﾟﾙ

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

primitive type は小文字ってのは Java あたりを踏襲した感じなのかね？

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

>>359
スマートポインタだけでは駄目で、 Rust で言うスライスみたいなものがないと安全に管理できない。
近年の C++ にはそういうライブラリも追加されたけどまだちょっと整備が不足している。
C++ は標準ライブラリには過剰なほど高い抽象度・汎用性を求めるので多次元のコンテナとの辻褄合わせでずっと議論してる……

**デフォルトの名無しさん** · 2024/08/23(金) 10:12:11.46

>>361
Cからずっとそうじゃないっけ？
組み込み型名はたいてい予約語で、予約語はたいてい小文字だからな気はする

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

>>363
いや、暗黙の前提として「標準ライブラリの型名は camel case なのに」ってのを含んでる。
つまり「primitive とライブラリを違えている」ということを話題にしたくて、それを原則にしている言語の例として Java を挙げた。

**デフォルトの名無しさん** · 2024/08/23(金) 12:43:06.00

RustでcamelCaseは用いない
基本型は小文字
structやenumで作る型および別名はUpperCamelCaseを用いる

例えばstrは基本型だから小文字
StringはstructだからUpperCamelCase

**デフォルトの名無しさん** · 2024/08/23(金) 14:34:53.94

strって言うほど基本型か？問題

**デフォルトの名無しさん** · 2024/08/23(金) 15:29:42.74

https://users.rust-lang.org/t/why-is-str-a-primitive-type/36551
ふーん

Javaとは違ってprimitiveかそうでないかによる重要な違いはなくて、別に区別する必要性はそこまでないし、気にするだけ無駄そう
名前持ちのprimitive型の中でstrだけがDSTなのが違和感の正体かも

**デフォルトの名無しさん** · 2024/08/23(金) 15:49:44.63

array(記述は[T; N])やslice(記述は[T])やstrはもちろん基本型
そしてヒープを必要としない
だからcoreにありno_stdでも使える

一方でBoxやVecやStringはヒープを必要とする
だからcoreにはなくallocにある

**デフォルトの名無しさん** · 2024/08/23(金) 20:34:48.59

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d8fa7bff7e61accb6f6bf7f0d4075dae

要素への不変参照を保ちつつ追加できるコレクションが欲しくて試しに書いてみたけど、どうすりゃいいんだ
UnsafeCell使うしかない？

**デフォルトの名無しさん** · 2024/08/23(金) 21:33:21.24

>>367
スライスとstrとdynはDSTだからこそprimitiveだよ
参照が他と異なりfatポインタになるからね
"あいうえお" を正規UTF8と定めた点もRustの良いところ
それをprimitiveな型strとしたのも良い判断だね

**デフォルトの名無しさん** · 2024/08/23(金) 21:41:42.80

>>369
それは単純に参照を借りっぱなしになってるエラー
どこまで何をしたいのかによるけど
そのコンパイルエラーを解消したいだけなら
Cons(T, Box<List<T>>)を
Cons(Rc<T>, Box<List<T>>)にして
Some(t)をSome(t.clone())すればよい
ちなみにUnsafeCellは内部可変性の源泉なので
そういう新たな汎用型を作る時に使うものでunsafeだよ
一般プログラマーは使ってはいけない

**デフォルトの名無しさん** · 2024/08/23(金) 21:46:56.38

名前に露骨に Unsafe って付いてるんだから十分な理解なしに使うのはやめておけという意図は感じるよな。

**デフォルトの名無しさん** · 2024/08/23(金) 21:47:30.17

>>370
UTF-32の方が単純で良かったんじゃないか？

**デフォルトの名無しさん** · 2024/08/23(金) 22:02:55.80

>>373
ファイルもネット通信もUTF8に統一されていってる状況だから
それらを無変換で済むUTF8がベストだよ
UTF32はメモリを無駄に消費してメリットがないよね

**デフォルトの名無しさん** · 2024/08/23(金) 22:05:42.82

UTF-8 はランダムアクセスに難があるが文字列のランダムアクセスってそんなに要らんだろという割りきりだな。
やりたければ UTF-32 用の型を使えるし、あくまでも言語の基本には UTF-8 を据えるってだけ。

**デフォルトの名無しさん** · 2024/08/23(金) 22:07:14.75

>>371
そこは一般プログラマーじゃないと仮定して、UnsafeCell使うならこんな感じでいいんですかね？
RustのUBにちょっと詳しくなくて

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

**デフォルトの名無しさん** · 2024/08/23(金) 22:26:58.16

UnsafeCellは内部可変性を持つ安全な型を作るためのunsafeな部品として存在している
目的外に使う人に対しては今後は他の質問についても答えない

**デフォルトの名無しさん** · 2024/08/23(金) 22:27:06.29

>>376
値が数値だから今のところ問題ないけどこの実装だとListを新しいConsに突っ込んだ瞬間に
先頭の値の参照先が無効になりそうだな

自作にこだわらないならtyped-arenaを使うといい
https://docs.rs/typed-arena/latest/typed_arena/
小さいライブラリだから自作の参考にもなると思う
ライブラリ使わないならどこかでunsafeは必要になる

**デフォルトの名無しさん** · 2024/08/23(金) 22:50:35.38

ちょっとuser-friendlyに整理してみた
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

>>378
ListNode<T>は絶対にBoxに包むようにして、itemはヒープ上のTを指してるので
unsafeの中で間違ってBoxをdropしなければ無効な参照は発生しないと思うんですが、どうなんでしょう

typed-arena!
存在は知ってたけど、RefCellと組み合わせてグラフをなんかいい感じに扱えるやつくらいの認識だったので完全に盲点でした
これでいけそうです、ありがとうございます

**デフォルトの名無しさん** · 2024/08/23(金) 22:55:03.65

おっとリンク再生成してなかった
ちょっとuser-friendlyに整理してみた版
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b0ca47dce14c07da2936f1964bc54485

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

安全だと思い込んでunsafeを使うやつはCでも使っとけ

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

依存クレートの中からunsafeを検索して一覧表示するようなツールある？

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

数えるだけならcargo-geiger
ナンセンスすぎて使ったことないけど

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

>>382
あまり意味がない気もする
actix-webの作者は「unsafe使うな」「それはRustのやり方ではない」という沢山の声にうんざりして開発停止する事件が起きた
unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う

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

unsafeは人間が安全性を保証しなければいけないため、必ず多くの監視者がいなければいけない。
そして不必要なコードと必要で安全なコードを皆で選別しなければならない。
パフォーマンスにほぼ影響なく無くせるケースは無くすべきというのが第一原則。

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

一方でRustの標準ライブラリには何千ものunsafeが存在していて、安全なインターフェースを提供してくれている。
このおかげで我々はunsafeを使わずにパフォーマンスの高いコードを書くことができる。
標準ライブラリと同様に他のクレートでも下支えをしてくれるものは同じ立ち位置として認められているものが多い。
つまり必要不可欠なものである。
いずれにしてもライブラリ内に隔離して外向けに安全なインターフェースを提供してくれることが第一原則。

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

Rust の参照についている様々な制約は機械的に解析可能なように制限したのであって
人間的な感覚での適切な抽象やデザインパターンと両立不可能な場合がある。
機械的検証可能性を維持するために不自然なデザインを持ち込むのが健全とは言い難いよ。

unsafe はなるべく低レイヤの小さな範囲に押し込めたほうが良いのは確かだが、
プロジェクトの性質によってはそれがもうちょっと高レイヤまではみ出してくることだってあるだろ。

**デフォルトの名無しさん** · 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でよくない？
反対意見あったら言ってくれ