Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

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

**デフォルトの名無しさん** · 2025/05/15(木) 20:29:13.48

俺だってシャワーズとセックスしたいよ

**デフォルトの名無しさん** · 2025/05/15(木) 22:09:10.96

それはもはやトランスアニマルじゃねーの
いくら翻訳がグダグダだからってそこまで人間性失うのはいかがなものかと

**デフォルトの名無しさん** · 2025/05/15(木) 22:20:07.26

>>457,466
ほかの言語と同じように外部ライブラリ/crateを除外してある今回の数字が正しそうね

**デフォルトの名無しさん** · 2025/05/15(木) 23:29:18.99

>>493
Orphanルールの説明で第三者による実装同士がぶつかりエラーを引き起こすためという話を見かけるけど
ぶつからなくても単独でもそういう支障があるんだよな

**デフォルトの名無しさん** · 2025/05/16(金) 06:25:07.48

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

**デフォルトの名無しさん** · 2025/05/16(金) 07:42:42.67

>>500
詳細を見るとこれはRustとLLVMの改善に大きく寄与しそうだな
(1) Rustコードの問題
(2) Rustコンパイラの問題
(3) RustコンパイラからLLVMへの問題
(4) LLVMの問題
これらは密接に関係していて(1)を完璧にしていても
(4)の問題から逆連鎖して(1)で対応するためのコード調整をしなければいけないようだ
本件をきっかけに様々な改善が期待できるので世界全体に役立つだろう

**デフォルトの名無しさん** · 2025/05/16(金) 07:44:33.05

LLVMを用いている様々な言語にも恩恵ありそうだ

＞驚くべきことに、Clang 18 でビルドされたバージョンは、Clang 17 でビルドされたバージョンよりもパフォーマンスが劣ることがわかりました (~3% 遅い)。
＞このリグレッションの原因は不明ですが、Clang全体で一貫性があり、対応するLLVMバックエンドを使用していることがわかりました。

**デフォルトの名無しさん** · 2025/05/16(金) 08:19:21.12

Rust は将来的に LLVM をやめる計画じゃなかったっけ？
うろ覚えなので勘違いかもしれんけど。

**デフォルトの名無しさん** · 2025/05/16(金) 08:21:41.68

>>503
GCC Rustは継続的にやってるみたいだけど、別にLLVMはやめないでしょ

**デフォルトの名無しさん** · 2025/05/16(金) 08:42:23.59

今日公開のRust 1.87.0でio::pipeが追加された
今までなかったことが不思議

**デフォルトの名無しさん** · 2025/05/16(金) 09:10:56.72

>>500
対象国に対して賞金が安すぎる
しかもRust処理系の方に手を入れた場合はアプリケーションの改善をした人と山分けになる可能性が高いし、
一般的な有効性を証明してRust処理系にマージされないといけないというのはハードルが高すぎる
残念ながら複おじが期待するような結果になる可能性は低いと言わざるを得ない

**デフォルトの名無しさん** · 2025/05/16(金) 09:12:43.25

>>505
Stdio::piped()が10年前からある
無名パイプはOS依存かつプロセス間だから汎用化は安定化に時間がかかったのかな

**デフォルトの名無しさん** · 2025/05/16(金) 09:41:55.75

>>500,506
フルで$20,000でも米国の1人月かぁ、しかも成功報酬だから最適化を舐め腐ってるけど
Rustに入れ込んでる一定数はひと山当てたい連中だから売名プロモーションとして参加するだろうね

**デフォルトの名無しさん** · 2025/05/16(金) 11:10:05.92

リンク先見たら初っ端からsafe rustを諦めているから
何の為のプロジェクトか意味不明になりかけている

**デフォルトの名無しさん** · 2025/05/16(金) 11:35:21.65

>>509
unsafeからsafeを創り出す新たな安全パターンを見つけたら、それを使うのは問題ない
その部分だけ徹底的に人の手で安全管理して、それ以外の安全をRustコンパイラに任せることができる
それらのうち特に汎用パターンを集めたものが標準ライブラリという視点もある

**デフォルトの名無しさん** · 2025/05/16(金) 11:41:45.02

今になって気が付いたじゃなくて、言語仕様で例外を投げられないから無視してただけでは
> We noticed that the existence of panicking code significantly increased stack usage. Similarly to how panicking/formatting code prevented crucial inlining in bounds checking code until moved out of the function, panicking code also increased stack usage and spills.

>>510
タラレバがでかい

**デフォルトの名無しさん** · 2025/05/16(金) 11:42:09.71

>>509
標準ライブラリの内部でも unsafe はたくさん使われてるぞ。
unsafe をどう「閉じ込める」かが Rust プログラムの構成の肝心な部分だ。
速度チューニングのために閉じ込めきれなかったのなら失敗と言えるが unsafe がただちに悪いわけではない。

**デフォルトの名無しさん** · 2025/05/16(金) 11:48:07.99

panic(エラー処理)を関数内に収めるからregisterが足りなくなり易くなるからspillさせるためにスタック多めにして、コードサイズも大きくなるのは最初から分かってたでしょうよ

**デフォルトの名無しさん** · 2025/05/16(金) 12:31:41.93

unsafeは禁止なのにpanic!はOKって何考えて設計してんの

**デフォルトの名無しさん** · 2025/05/16(金) 12:37:23.64

速度にシビアなコードを書く時は関数にpanic呼び出しが残っていたら当然負け
まずはpanicを生じさせないイテレータなどで書き
インデックスアクセスを避けられない時は様々な工夫とヒントをコンパイラに与えて境界チェックを回避
それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
他の言語なら全体の安全保証を捨てるか遅さを我慢するかの二択

**デフォルトの名無しさん** · 2025/05/16(金) 12:56:20.34

一番初歩的なゼロ除算はchecked_divがidiomaticだけど、
ttps://stackoverflow.com/questions/66602948/is-there-a-way-to-catch-division-by-zero-errors-without-checking-in-advance

実際に0除算を実行してハードウェア例外を発生させるコードの例(回避できない部分と仮定)として、
> それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め
>>515の言うこれをゼロ除算で具体化するとどうなるの？

**デフォルトの名無しさん** · 2025/05/16(金) 13:18:06.79

>>516
除数をstd::num::NonZero型にするとpanicコードは入らない

**デフォルトの名無しさん** · 2025/05/16(金) 13:42:02.34

>>517
病気かな

**デフォルトの名無しさん** · 2025/05/16(金) 13:49:45.88

>>518
実際にかつてそれで対応したことがありアセンブリコードも確認している

**デフォルトの名無しさん** · 2025/05/16(金) 13:54:06.57

>>519
要求されてるのは>>515「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例だからサッと出せば良い

**デフォルトの名無しさん** · 2025/05/16(金) 14:18:57.81

>>520
safeなstd::num::NonZero使用で対応できているためunsafeの必要がない

**デフォルトの名無しさん** · 2025/05/16(金) 15:05:55.72

>>521
御託はもういいからお前はsafe縛りでAV1デコーダを書き直してCと同等の速度を達成してこい

**デフォルトの名無しさん** · 2025/05/16(金) 15:14:15.36

>>522
金と暇を用意してくれたらな
それから最高速を求める時にsafe縛りの必要はない
unsafeを安全に閉じ込められる枠組みが見つかればそれを実行してきたのがRustの歴史
その恩恵で皆がsafe Rustでパフォーマンスを出すことができる

**デフォルトの名無しさん** · 2025/05/16(金) 15:24:17.43

なんかよくわかんねーけどCより5%遅いらしいな

**デフォルトの名無しさん** · 2025/05/16(金) 15:38:32.38

デコーダーの主要部分はC版の頃からアセンブラで書かれてて、Rustはグルーコードに過ぎないみたい

**デフォルトの名無しさん** · 2025/05/16(金) 15:41:24.82

えぇ・・・

**デフォルトの名無しさん** · 2025/05/16(金) 16:18:41.85

pub const fn checked_div(self, rhs: Self) -> Option<Self> {
if intrinsics::unlikely(rhs == 0 || ((self == Self::MIN) && (rhs == -1))) {
None
} else {
// SAFETY: div by zero and by INT_MIN have been checked above
Some(unsafe { intrinsics::unchecked_div(self, rhs) })
}
}

NonZero使ったら最適化で分岐が消える場合があるってことだろうけど
チェックタイミングがNonZero化するときに移動しただけだよね
もしくは定数由来だからチェックが不要になったか

**デフォルトの名無しさん** · 2025/05/16(金) 19:03:43.29

>>527
checkなくコストゼロでpanicもなく安全にu64 / NonZero<u64>の除算やNonZero<u64>→u64の変換などができる
ゼロ保証のない変数からNonZeroを作るには必ずチェックコストがかかるが以降は除数として何度使ってもコストゼロ

元が穴のないCコードならどこかで何らかの方法でゼロにならないことを保証しているはず
それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる
もし元のCコードにゼロ保証する仕組みが全く見当たらないならばそれは穴のあるコードが見つかったことになる

**デフォルトの名無しさん** · 2025/05/16(金) 19:13:36.61

>>528
病気だな。

要求されてる「それでも回避できない部分が残れば最後の手段unsafe安全閉じ込め」™の具体例を上げやすいように、
「それでも回避できない部分」を簡潔に作り出すのが手間なら、ループ最深部の(0かも知れない)除算を想定した上で「unsafe安全閉じ込め」™をサッと挙げたらどうですか？
と言う話のはずなのに、この受け答え。

**デフォルトの名無しさん** · 2025/05/16(金) 19:16:32.12

>>529
unsafe使わずにsafe Rustで実現できている
何のためにunsafeを使えと言ってるのか理解できない

**デフォルトの名無しさん** · 2025/05/16(金) 19:17:47.42

>>528
> それに準拠する形を取ることができればCとRustは同じコストで同じ速さになる

こんな単純化を信じているのが大勢いて、信者の一人>>500記事が現実を突きつけられているのに
>>528はまだ受け入れられない。

**デフォルトの名無しさん** · 2025/05/16(金) 19:19:01.24

>>530
対象国居住者とタッグ組んで参加してください。

**デフォルトの名無しさん** · 2025/05/16(金) 19:23:03.68

>>525
> Rustはグルーコードに過ぎないみたい

グルーコードに過ぎないのに、最大限努力した結果で5%も性能差が出ている事実がインパクトある。

**デフォルトの名無しさん** · 2025/05/16(金) 19:29:28.60

>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで実現する方法は既に使えた

**デフォルトの名無しさん** · 2025/05/16(金) 19:33:14.79

当然ながら元々はボトルネックを特定した上で部分的にアセンブラで書いているのだろうし、
当時のスキルをもってすれば今5%も差が出ているならまずは原因箇所の特定くらいは簡単にできそうなもんだが、
なぜこんな解像度の低い状態で丸投げしているのか謎
オリジナルの開発をやった人がいなくなっちゃったのかもね
もはやRust関係ないけど

**デフォルトの名無しさん** · 2025/05/16(金) 19:35:12.11

>>531
何を解決してほしいのか具体的に言おう
panicもcheckも必要なく安全にsafe Rustで割り算を実現する方法は既に伝えた

**デフォルトの名無しさん** · 2025/05/16(金) 19:39:18.59

ここでは全部一人のせいにしているけど
だぶん「unsafe安全閉じ込め」™オジwと複オジは別人で
都合悪なると仮病になる

>>535
懸賞記事内にリンク記事があるよ

>>534,536
たぶん「unsafe安全閉じ込め」™が何のことか具体的に知りたいだけでは
仮病してると複オジと同レベルだぞw

**デフォルトの名無しさん** · 2025/05/16(金) 19:45:26.73

>>537
「unsafe安全閉じ込め」の例はRust標準ライブラリに無数にあるからそれを知りたいとは思わなかった
興味ある部分についての標準ライブラリのソースを読んでくださいでおしまい

**デフォルトの名無しさん** · 2025/05/16(金) 19:48:17.71

いつもの人間が判断するだけの事に名前を付けたのね

**デフォルトの名無しさん** · 2025/05/16(金) 19:49:07.71

そうなると複オジ本人だなw

**デフォルトの名無しさん** · 2025/05/16(金) 20:03:38.49

>>537
一通り読んだけど、c2rustのunsafeコードを修正する際に適用することにしている、一般的に高速化に寄与すると考えられる作法を紹介しているだけで、
実行時のパフォーマンスについての詳細な分析結果は特に見つけられなかった
プロジェクトの概要なんかも見てると金貰って開発する上で結構厳しくQCD管理されてるみたいだから、
どうしても自分達で解決できないというよりは単に切羽詰まってるから助けてくれという感じなのかね

**デフォルトの名無しさん** · 2025/05/16(金) 20:14:28.07

複オジは仮病だろうけど、最近の話題でこんな画像があった

統合失調症のブログが話題に「全てがわかる。すべてのすべて」
https://pbs.twimg.com/media/Gpy43ktaYAYMz9w.jpg

**デフォルトの名無しさん** · 2025/05/16(金) 23:32:05.70

>>513
この種の速さ命のプログラミングではpanicコードを完全に排除するためその問題は起きない

**デフォルトの名無しさん** · 2025/05/16(金) 23:35:06.70

テックポエム量産してるのは>>542に近いのでは
論理的には違っていると自覚はあるから「ポエム」と称するけど
異常脳神経が「分かった」シグナルを発して仕方がないのだろう

**デフォルトの名無しさん** · 2025/05/16(金) 23:48:27.11

このGoスレレスなんて>>542のイチゴの例そのものね

> Goはルーン文字と同じ運命をたどりそうだな
> 紙が普及した時代に原始的な彫刻文字は流行らない
> 時代に合わせて形を変えないと

**デフォルトの名無しさん** · 2025/05/17(土) 02:16:37.18

>>545
頭おかしいのはみんな気づいてるからいいとして、せめてコテにしてNGさせてくれよな
延々中身のない仕様も理解していないレスバを目にするのも辛いしな
よりに寄ってこんな過疎スレに来なくていいのに

**デフォルトの名無しさん** · 2025/05/17(土) 07:06:56.82

科学＋ 5ch

20種近くも検出された新しい「量子状態」は、量子コンピューター飛躍の鍵になるか [すらいむ★]
2025/05/16(金) 22:52:02.48
http://egg.5ch.net/test/read.cgi/scienceplus/1747403522/
>>これまで理論上の存在と考えられてきた量子状態の検出に、国際研究チームが初めて成功した。量子情報の保存や論理演算の基盤として応用することで、量子コンピューターの未来を変える鍵となるかもしれない。

※犯罪の手口が判明するのか

**デフォルトの名無しさん** · 2025/05/17(土) 07:42:04.23

>延々中身のない仕様も理解していないレスバ

潰し屋だな

**デフォルトの名無しさん** · 2025/05/17(土) 08:40:26.34

全能感があるだけ幸せなのでは？自分は真逆で老化がはじまったんかと思うぐらい

**デフォルトの名無しさん** · 2025/05/17(土) 10:25:49.04

糖質というより発達系だろ
間違いを認めたら負けみたいな中華メンタルも持ち合わせてるけどあれは病気じゃなくて人間性の問題

**デフォルトの名無しさん** · 2025/05/17(土) 10:34:31.56

キチガイの自白で荒らされてますが
Rust 1.0からちょうど10周年ですよ
おめでとう！

**デフォルトの名無しさん** · 2025/05/17(土) 10:41:03.44

Rustのすべてが正しいという発想しかない異常者

**デフォルトの名無しさん** · 2025/05/17(土) 10:49:42.53

複オジ今日も快調に暴走

**デフォルトの名無しさん** · 2025/05/17(土) 15:50:10.71

複ちゃん消したらもうこのスレの存在意義ないけど

**デフォルトの名無しさん** · 2025/05/17(土) 18:34:13.65

AI吹くちゃん二代目襲名

**デフォルトの名無しさん** · 2025/05/17(土) 19:44:04.18

1.87で安定化したVec::extract_ifの機能がdrainに近いと思ったけど最初はdrain_filterの名前で提案されてたのね
自動で全部dropできないからdrain_filterとかdrain_ifだとだめらしい
drainが排出じゃなく吸収のイメージなのはFFが原因だな

**デフォルトの名無しさん** · 2025/05/17(土) 22:10:30.09

extract_if()はむしろretain()＋捨てる分を取り出し(extract)と考えた方がいい
ただし残すをtrueか取り出すをtrueかで判定関数の真偽が逆に注意
ついでに判定関数の引数が&vec[i]から&mut vec[i]に変わってるため残すものも値書き換え可のおまけ付き

**デフォルトの名無しさん** · 2025/05/17(土) 22:46:26.94

返されたイテレータを使い切らないと全部削除されないからretainとも微妙に違う
nextで取った分だけ削除だからpeekableとの取り合わせが悪そう

あと関数名はextract_ifじゃなくextractだけでよかった気がする
extractがないのにextract_ifがあるのは何かバランス悪い
drain_filterから紆余曲折あったみたいだから仕方ないけど

**デフォルトの名無しさん** · 2025/05/17(土) 23:12:09.74

>>558
書いた通り、retain()＋捨てる分を取り出し(extract)
だから取り出さないと削除されない
イテレータが進んだ分だけretainと一致する

名前の_ifはすぐに類似のpop_ifが想起される
pop_ifでも条件判定の引数が可変参照で同じだからrangeをlastにしたものと見なすことができる
ifの付かないpopは無条件だから
ifの付かないextractも無条件となる
だからextract_ifというメソッド名が正解で一貫している

**デフォルトの名無しさん** · 2025/05/18(日) 00:31:27.80

すでにドレンフィルタって名称の一般的なものがあるけど…
排水管などのフィルター

**デフォルトの名無しさん** · 2025/05/18(日) 00:55:22.32

coffee extractionはコーヒー豆の方を取り除いているのか液体(エキス?)を抽出しているのか

**デフォルトの名無しさん** · 2025/05/18(日) 01:05:08.64

extract は語源的には ex (外へ) - tract (引っ張る) だから、「取り出す・抽出する」といった意味合いが強い

**デフォルトの名無しさん** · 2025/05/18(日) 01:06:15.76

コーヒー豆とコーヒーが混ざった物からコーヒーを抽出するよね
それをコーヒーを捨てているとは言わない

残ってる方は最後まで濾さないとコーヒー豆とコーヒーが混ざった物でしかないので無価値
一方で抽出したほうはコーヒーなので価値がある
この意味が判るかどうか？

**デフォルトの名無しさん** · 2025/05/18(日) 07:46:36.17

企業献金、結論先送りへ　自公国法案、提出取りやめ [蚤の市★]
2025/05/17(土) 21:17:14.36
https://asahi.5ch.net/test/read.cgi/newsplus/1747484234/

全国1万1155の企業・団体の政治献金「97％」が自民へ、シンクタンク調査 [おっさん友の会★]
2025/05/14(水) 11:12:39.51
https://asahi.5ch.net/test/read.cgi/newsplus/1747188759/

**デフォルトの名無しさん** · 2025/05/18(日) 09:41:45.81

Vecに含まれる構造体を参照しながら、別の構造体に変更を加える処理ってどれがベストでしょうか

**デフォルトの名無しさん** · 2025/05/18(日) 10:17:55.24

これは任意の方苦に向けて電波攻撃可能ということでしょうか？
プログラムの改造で下記が可能になるのでしょうか

「Xperia」が電波法違反、ソニーに行政指導--総務省
2024年12月13日 15時23分
https://japan.cnet.com/article/35227306/
>>スマートフォンにおいて「工事設計認証を受けた工事設計にない空中線を使用しての電波発射が可能な仕様となっている状態にあった事実が認められた」という。

**デフォルトの名無しさん** · 2025/05/18(日) 11:19:10.16

>>565
色々方法があってどれがベストかは状況による

a. 変更内容を作成する処理と変更を適用する処理を分離する
b. split_mut系で更新部分と参照部分のスライスに分割する
c. takeとかreplaceで変更対象の構造体を一旦Vecから取り外す
d. Vec内の構造体を全部RefCellに入れる

可能ならaがベストかな

**デフォルトの名無しさん** · 2025/05/18(日) 11:30:08.35

よくそんな意味不明な質問に答えられるなと思う
自分がアホなのか、予定された質問に予定された答えなのかわからない
本当にわからない

**デフォルトの名無しさん** · 2025/05/18(日) 11:41:01.25

>>567
かなり曖昧な質問に答えてくれてありがとう。
他の言語だとリストから参照で構造体を取り出して、他の構造体を変更したり色々できたけどRustだとかなり制限がキツくて躓いた。ChatGPTにも聞いたりだけどイマイチ納得できなくて、実際使ってる皆さんに聞きたくなったんだよね。

**デフォルトの名無しさん** · 2025/05/18(日) 11:44:13.33

ChatGPTに聞いたなら質問を清書してくれただろ？
そっちを貼ればいいだろ？
謎すぎる

**デフォルトの名無しさん** · 2025/05/18(日) 11:45:25.47

意味不明な質問というのには完全に同意
質問と回答が矛盾してるので
さすがにこれは発達オジの自作自演ではないだろう

**デフォルトの名無しさん** · 2025/05/18(日) 11:47:57.87

あ・・・
自分の中では矛盾してなかったみたいww

自作自演発達オジの日本語能力の問題だったか

**デフォルトの名無しさん** · 2025/05/18(日) 11:48:09.03

やりたいことは、構造体には関数も実装ししていて、その関数に大元のVecを渡してそれぞれの要素に変更をかけるみたいなやつだけど、ミニマムで質問してみた。一旦教えてもらったcに近い実装でコンパイル通ったけど、モヤモヤしたので聞いてみました。

**デフォルトの名無しさん** · 2025/05/18(日) 11:48:46.66

>>570
確かに、、、すまぬ

**デフォルトの名無しさん** · 2025/05/18(日) 11:52:57.81

「別の構造体」というのは「同じVecの別の位置にある要素」という意味？
values[0] を参照しながら values[1] を変更するみたいな

**デフォルトの名無しさん** · 2025/05/18(日) 11:57:42.82

>>565
一般的にそういう時は困っていることが成立している最小構成例を具体的に出す
何通りにも解釈できる意味不明な曖昧な文章では答えてくれる人も減るだろう

>>568
意味不明な文章だがRustのプログラミング経験があるならば
質問者の脳内の仮定を補完して最も可能性の高い質問ケースとして回答者が応じている状況を観察できるはずだ

**デフォルトの名無しさん** · 2025/05/18(日) 11:58:51.15

書き方が回りくどいね　わかりやすく

**デフォルトの名無しさん** · 2025/05/18(日) 12:05:59.38

>>575
そうです、言葉足らずでした。。。

**デフォルトの名無しさん** · 2025/05/18(日) 12:21:21.33

>>578
それはRustだと面倒なパターンなので仕方ない
{} でブロックを作って借用のスコープを短くする等でなんとかする
ここはボローチェッカーの気持ちの理解が必要
(なぜダメなのかはエラーメッセージが教えてくれてるから、そこは既に分かってるかもしれないけど)

同じことは構造体の別のフィールドを参照する場合も言える
構造体のフィールドaを可変借用しつつ別のフィールドbを参照するなど

**デフォルトの名無しさん** · 2025/05/18(日) 12:26:55.54

う～ん
　何が言いたいかわからる人にはわかるだろ？

**デフォルトの名無しさん** · 2025/05/18(日) 12:29:43.83

何がやりたいのか全然わからん。
コードで示してよ。
コンパイル通らなくてもいいから Rust 風擬似コードって感じで。

**デフォルトの名無しさん** · 2025/05/18(日) 12:54:12.76

複おじちゃんは今日もやらかしてるね
特有の癖が出てるのに自分ではバレてないと思ってるから面白い

**デフォルトの名無しさん** · 2025/05/18(日) 13:00:12.37

困ったことが起きたらその問題が再現する最低限の最小構成コードを書いてみる
すると本質的な構造が見えてくる
その過程で自己解決することも多いだろう
わからなくてもその最小構成コードを貼って質問すればよい

**デフォルトの名無しさん** · 2025/05/18(日) 13:58:46.67

>>579
やはりそうなんですね。ありがとうございます。

>>581
>>583
助言ありがとうございます。
ChatGPTにサンプルコード作ってもらいました。コンパイルは通らないですが、やりたいイメージはこんな感じです。

struct Unit {
id: usize,
hp: i32,
}
impl Unit {
fn act(&mut self, all_units: &mut Vec<Unit>) {
// 自分以外のユニットに攻撃したい
for unit in all_units.iter_mut() {
if unit.id != self.id {
unit.hp -= 10;
}
}
}
}
fn main() {
let mut units = vec![
Unit { id: 0, hp: 100 },
Unit { id: 1, hp: 80 },
Unit { id: 2, hp: 60 },
];
for unit in units.iter_mut() {
unit.act(&mut units); // ❌ コンパイルエラーになるが、やりたいことはこんな感じ
}
}

**デフォルトの名無しさん** · 2025/05/18(日) 14:03:53.58

>>584
これも追加

// 自分以外のユニットに攻撃したい
↓
// 自分以外のユニットから奪い取る

if unit.id != self.id {
unit.hp -= 10;
self.hp += 10;
}

**デフォルトの名無しさん** · 2025/05/18(日) 14:16:39.01

自作自演スレ

**デフォルトの名無しさん** · 2025/05/18(日) 16:37:58.98

>>585
こんなのでどうだろう
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=871e0b5209dab043741c765000be6e5a

他言語からすると面倒に感じるかも
「要素 i への可変参照を持ちつつ、Vec全体への可変参照を持つ」のは借用チェッカーに引っかかるパターン
if unit.id != self.id の判定が必要なように「all_unitsの中にunitがいるかもしれない」という状況をそもそも借用チェッカーは防ぎたいので

なので、 split_at_mut() を使って参照範囲を ([i] への可変参照, 他の要素への可変参照) に分けてみた

他には Cell (内部可変性) を使うパターンもあるけど、このケースでこれを使うのはちょっと微妙な気がする

**デフォルトの名無しさん** · 2025/05/18(日) 16:40:13.34

>「all_unitsの中にunitがいるかもしれない」という状況
訂正:「all_unitsの中に自身がいるかもしれない」という状況

**デフォルトの名無しさん** · 2025/05/18(日) 16:59:42.16

あんまりアドホックな対応で頑張ってもまた同様の問題でいちいち詰むよ
エンティティなんだから素直に内部可変性を使っておいた方が無難
僅かに遅くはなるだろうが、メモリアクセス効率まで気にするならECSパターンでも覚えた方がいい

**デフォルトの名無しさん** · 2025/05/18(日) 17:43:23.59

スライスを(init, mid, tail): (&[T], &T, &[T])に分割するsplit_midがほしいな
何かで似たような戻り値の型を見た記憶があるけど

**デフォルトの名無しさん** · 2025/05/18(日) 18:24:32.38

1つだけ外したい場合はOption+mem::take/replace使うのが自然だと思う
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a84a532ace40d2bb6603510ca1307756

**デフォルトの名無しさん** · 2025/05/18(日) 19:24:49.27

590だけど1.86で追加されたget_disjoint_mutが使えるかもしれない
少し癖があるけどsplitの代替になるかな

fn main() {
let mut v = vec![1, 2, 3, 4, 5];
let len = v.len();

for i in 0..len {
let Ok([init, [mid], tail]) = v.get_disjoint_mut([0..i, i..i + 1, i + 1..len]) else {
panic!();
};
*mid *= 2;
println!("{init:?} {mid} {tail:?}");
}
}

**デフォルトの名無しさん** · 2025/05/18(日) 21:02:54.43

>>584-585程度でこんなんか
安全パターンをプリミティブに単体分離しようと頑張るのは無駄なんだな
結局は要素還元できなくて逆に組み合わせ爆発しそう

**デフォルトの名無しさん** · 2025/05/18(日) 21:12:32.00

>>587
>>591-592
ありがとうございます！大変ためになります。
可変借用ルールの影響を受けないように分離するのが良いのですね。

>>585
私はこの方ではないが、これはこれで知りたかったので、それも解決出来る書き方にもなってるので助かります。

>>589
確かに複雑になってくるとまた沼りそうな気はしますね、内部可変性というのも調べてみます。

**デフォルトの名無しさん** · 2025/05/18(日) 21:37:30.85

借用チェッカの気持ちとしては、同じオブジェクトへの可変参照が複数ある状態を防ごうとするんだよね

fn act(&mut self, others: &mut [Unit]) { }

の中で、 self を操作しただけで others に影響が出たり、 others への操作が self に影響したりするというのは
潜在的なバグの原因になり得る (読み手にとって意図せぬ動作になり得る) から、そうならないことをコンパイル時に保証しようとする

なので >>587 では、act に渡された時点で self と others は確実に違うものだと分かるコードにすることで、借用チェックの条件をクリアしている

内部可変性は逆に、コンパイル時はいったん不変参照ということにしておいて、実行時に可変借用として取り出すための型
これは「同じオブジェクトへの可変参照は同時に一つまで」というルールを、借用チェッカーではなく自己責任で行うという考え
(「可変参照は同時に一つまで」というルールは変わらないし、実行時にこれを検査する動作になるので、若干のオーバーヘッドはある)

個人的には >>589 も納得できる考えで、エンティティ (idで同一性を検査するオブジェクト) ならそれでいいよねとも思う

Async が絡むと Mutex という別の型 (これも内部可変性と関係する) が出てくるけど、これはまた別のトピックになるので割愛

**デフォルトの名無しさん** · 2025/05/18(日) 22:38:23.16

なにかへまったら話題変更のために自演を始めるんかな？
と思ってしまう

いつも大体そんな流れだし急にポップしてくるこのスレの話題は理論寄りが多いのも変な感じする