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/03/18(土) 11:40:54.04

>>186
>>177て”公式”のThe Bookに書いてあったっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:42:47.58

lifetime 周りは書いてあるだろ

**デフォルトの名無しさん** · 2023/03/18(土) 11:53:17.34

>>188
>>181とかどこだっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:57:09.36

>>185
ライフタイムは全てにあるが省略できることが多い
省略できないときはコンパイラがエラーとし教えてくれるのでライフタイムを付ければいい

>>186
日本語版もある
https://doc.rust-jp.rs/book-ja/

**デフォルトの名無しさん** · 2023/03/18(土) 14:05:24.60

>>190
誤訳だらけの粗悪な非公式日本語訳はお勧めしない
簡単なエラーメッセージの意味も分からないような状態なんだからまずは公式The Bookをしっかり読むべき

**デフォルトの名無しさん** · 2023/03/18(土) 16:08:20.29

「非公式な日本語訳」を「日本語版」と呼称するのはそれがあたかも公式かのように錯覚させる意図が見えるので優良誤認の疑いがある

**デフォルトの名無しさん** · 2023/03/18(土) 16:13:56.89

>>187
The Bookはクックブックじゃないからな
特定の方法が書いてるか書いてないかよりも
読んで理解してれば自己解決できる問題かどうかが重要

**デフォルトの名無しさん** · 2023/03/18(土) 17:11:12.32

日本語訳の話題は生産的じゃないのでやめよう
このスレのローカルルールは>>37の通り

**177** · 2023/03/18(土) 18:27:39.58

読んだのは日本語訳のほうの The book ですが、個々の機能はたぶん分かってると思います。
ライフタイムを省略した場合には一定のルールで補われることも知ってました。
ただ、型が満たすべき性質を書くのが where 句なので (エラーメッセージを見てすら！) ライフタイムが必要ということがぴんと来なかったというのと、
引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。

**デフォルトの名無しさん** · 2023/03/18(土) 18:38:31.92

> 引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。
英語版でも日本語版でもどっちでもいいけど 10.3 にちゃんと書いてあるよ

**デフォルトの名無しさん** · 2023/03/18(土) 19:09:39.09

whereの:の左辺に参照とか書けるのをまず知らなかったんでしょ
the Bookにそんな例無いし

**デフォルトの名無しさん** · 2023/03/18(土) 19:27:58.81

日本語版を読まなければこんなことにはならなかった
日本語版を許すな

**デフォルトの名無しさん** · 2023/03/19(日) 04:14:30.76

>>183
ラストコンパイラって響きカッコいいな

**デフォルトの名無しさん** · 2023/03/19(日) 13:06:57.80

>>193
この場合に必要なのはクックブックだろ。
せめて>>196みたいに誘導しないと。

「読んで理解すれば自己解決できる」とか、そもそも読むところも示していないのにできるわけない。読み手を無視してマウントする自慰行為にしか見えん。

**デフォルトの名無しさん** · 2023/03/19(日) 13:09:44.94

そりゃ「個々の機能はたぶん分かってると思います」とか言われたら分かってねーじゃんって言いたくなるだろ

**デフォルトの名無しさん** · 2023/03/19(日) 13:23:44.49

>>196
where 句の制約で書いてる事例はないよ。

**デフォルトの名無しさん** · 2023/03/19(日) 14:19:01.09

>>200
訳の分からない日本語訳読んでわかったつもりになってるだけだからそう感じるんだよ
つべこべ言わずに全部読め

**デフォルトの名無しさん** · 2023/03/19(日) 14:25:09.74

>>202
grepだけじゃ答えは見つからない
読んでないから調べ方もわからない

**デフォルトの名無しさん** · 2023/03/19(日) 20:29:29.27

>>203
順調に日本Rustは錆びているようですね。いや、めでたい。

**デフォルトの名無しさん** · 2023/03/19(日) 20:49:16.05

ちゃんとあるじゃん
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html#%E3%83%A9%E3%82%A4%E3%83%95%E3%82%BF%E3%82%A4%E3%83%A0%E6%B3%A8%E9%87%88%E8%A8%98%E6%B3%95

**デフォルトの名無しさん** · 2023/03/19(日) 21:36:02.67

Rustはベンチマーク速いから気になってるんだけど
iPhoneやAndroidの開発で将来的に使えるようになる話はないの？

**デフォルトの名無しさん** · 2023/03/19(日) 21:40:34.06

ゴミだな

**デフォルトの名無しさん** · 2023/03/19(日) 21:41:36.36

>>207
普通に使えるやろ

**デフォルトの名無しさん** · 2023/03/19(日) 21:48:03.22

>>177見て思うんだじぇど
ゆとり教育超大国日本ではゆとり脳な奴が多数になって
エラーがでたよ、でも、エラー内容は書かないようなコミュ力の低い奴が
普通になっているんかな。

**デフォルトの名無しさん** · 2023/03/19(日) 22:05:41.03

>>210
いくつか落ち度はあっても>>177は自分の考える最小限の再現可能なコードを提示してるからめっちゃくちゃマシな質問者
質問者としての偏差値63くらい

**デフォルトの名無しさん** · 2023/03/19(日) 22:08:47.66

5chでの偏差値ね
Stackoverflowだと47くらい

**デフォルトの名無しさん** · 2023/03/19(日) 22:25:46.74

>>207
ネイティブコンポーネントには Rust は使える。
Android の根本設計が Linux+JVM で、 JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。
LLVM バックエンドで JVM バイトコードを生成するものもあるらしいから無理すりゃ Rust でもなんとかなるかもしれないけど……
それよりも現在の情勢を見ると Android に WASM サブシステムが入るとかのほうがあり得そうな気がするよ。

**デフォルトの名無しさん** · 2023/03/20(月) 00:55:07.77

自然言語自体に落ち度があると思った方がプログラミング言語の価値が分かりやすい
翻訳にも質問にもChatGPTにも過度の期待をしなくてすむ

**デフォルトの名無しさん** · 2023/03/20(月) 01:31:12.77

言語の問題と言語を扱うやつの問題を同一視するアホ

**デフォルトの名無しさん** · 2023/03/20(月) 01:42:28.65

正常動作する正規品を期待してたのに
不具合だらけで役に立たないジャンク品でした

**デフォルトの名無しさん** · 2023/03/20(月) 02:15:13.67

はした金ではジャンク品しか買えない
インフレか
物価の問題と品質の問題のような二つの問題を無関係と考えるのがアホだったんじゃないか？

**デフォルトの名無しさん** · 2023/03/20(月) 03:09:08.81

prettierの代替のdprintがRust製だった
普及してるものがRust製に置き換わるってが今後も続くだろうね

**デフォルトの名無しさん** · 2023/03/20(月) 03:46:46.02

>>217
ところが実際はジャンク品のほうが正規品より高いんだなこれが
正規品に見せかけて売ってるからいわゆるジャンク扱いではなく蓋を開けたらゴミでしたという落ち

でもありがたいことに今は購入前に中身を確認可能なのでよほどの情弱じゃなければ騙されないんだけどね

**デフォルトの名無しさん** · 2023/03/20(月) 10:04:17.69

>>217
物価の意味も知らんのかww
恥ずかしいから辞書引けよ

**デフォルトの名無しさん** · 2023/03/20(月) 10:58:26.51

このあたりを読んでおけば大丈夫
Advanced Lifetimes
https://doc.rust-lang.org/1.30.0/book/second-edition/ch19-02-advanced-lifetimes.html

**デフォルトの名無しさん** · 2023/03/20(月) 11:08:21.33

>JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。

相変わらずいい加減なこと書いてるなぁ

**デフォルトの名無しさん** · 2023/03/20(月) 11:41:00.74

アプリもコンパイラも動くLinuxが正規品
コンパイラは不要とされアプリしか動かないLinuxがジャンク

**デフォルトの名無しさん** · 2023/03/20(月) 11:59:59.11

>>223
GNUにケンカ売る気かよ

**デフォルトの名無しさん** · 2023/03/20(月) 14:23:43.87

**デフォルトの名無しさん** · 2023/03/20(月) 17:14:18.78

flattenとかflat_mapとかfilter_mapとか

**デフォルトの名無しさん** · 2023/03/20(月) 19:58:13.92

flat_mapはmap(f).flatten()の順だから無理だな
filter_mapはOption外しに使えるがmap(f)は別途必要
filter_map(|opt| opt).map(f)　または参照なら
filter_map(Option::as_ref).map(f)
したがって正解はこれ
flatten().map(f)

**デフォルトの名無しさん** · 2023/03/20(月) 20:22:03.14

flattenのOption/Resultはずし知らんかった

**デフォルトの名無しさん** · 2023/03/20(月) 20:32:22.28

>>227
どれでもできるぞ
初手で一番素直な選択はfilter_map

**デフォルトの名無しさん** · 2023/03/20(月) 20:46:14.12

flattenを使ってできました
let v = vec![None, Some((1, 2)), None, Some((3, 4)), None];
assert_eq!(14, v.iter().flatten().map(|(a, b)| a * b).sum());

>>229
filter_mapを使うと簡単ならば知りたいです

**デフォルトの名無しさん** · 2023/03/20(月) 21:35:03.62

複オジかよっw

**デフォルトの名無しさん** · 2023/03/20(月) 21:41:30.44

前述したようにfilter_map自体のmapではOption外ししかできないので別途map(f)が必要になる
filter_map(|opt| opt).map(f)
あるいは
filter_map(|opt| opt.map(f))
簡単なのはflatten().map(f)

**デフォルトの名無しさん** · 2023/03/20(月) 23:15:03.64

flat_mapはfilter_mapを汎用化したものなので
filter_mapは常にflat_mapで書き直せる
flattenと理屈は同じ

**デフォルトの名無しさん** · 2023/03/20(月) 23:20:21.79

唐突に妙に具体的な質問が飛んできたらあの人だと思ってればいい

**デフォルトの名無しさん** · 2023/03/20(月) 23:20:56.30

どの人だよ

**デフォルトの名無しさん** · 2023/03/20(月) 23:49:46.77

>>234
いやー俺は今回まんまと騙されたわ
自演力と自画自賛力にステ振りすぎとちゃう？

**デフォルトの名無しさん** · 2023/03/21(火) 00:12:49.49

>>226 >>233
質問はOption列が対象のようだからflat_mapとfilter_mapは対象外やろ
それらはむしろOptionを作る関数を与えて使う
元から既にOptionになってるのだからflattenが正解

**デフォルトの名無しさん** · 2023/03/21(火) 10:42:06.27

Someだけ拾って関数をmapすると考えれば
filter_map(|opt| opt.map(f))
だな
元のSome/Noneをそのまま利用するのがトリッキーかもしれないけど

**デフォルトの名無しさん** · 2023/03/21(火) 11:33:54.48

ところで、ラムダには自由変数というものがありその反対が束縛変数だが
ラムダや自由変数を意識する必要がない文脈で束縛という用語が出ると
その語源を説明する手間がかかるよな

**デフォルトの名無しさん** · 2023/03/21(火) 13:02:51.29

scalaやっているせいかmatchとか
すごく使いやすいわん
iterator nextなんてJavaでも使わんけど
これ使い人いるの？

**デフォルトの名無しさん** · 2023/03/21(火) 13:17:10.53

>>240
nextはIterator全ての基礎
nextだけを定義すれば他のメソッドはnextで作られているので自動的に定義される
for文もnextを使っている

**デフォルトの名無しさん** · 2023/03/21(火) 13:27:49.15

>>238
入力から出力までのパイプラインの全体像を見ればトリッキーに感じることはないと思うよ
例えば>>230にあるvec![None, Some((1, 2)), None, Some((3, 4)), None];みたいなのはこれがすでに入力値に対して何かしら関数適用した結果なんだよね

**デフォルトの名無しさん** · 2023/03/21(火) 13:35:41.08

>>242
関数適用せずとも
None初期化配列やVecで一部indexにだけ値がSomeは普通によくあるパターン

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

元の入力で「値の有無」を表してたOptionをfilter_mapの「要素の残存判定」に転用する形だから
Optionの意味が微妙に変わってて引っ掛かる人もいるかなって思った

**デフォルトの名無しさん** · 2023/03/21(火) 14:35:08.73

昔の言語だと配列に初期値として使っていないことを示すために-1とか0とかnullとかundefinedを入れてしまうことが多かったパターンか
いわゆるデータのnull安全性がなかったことろをRustはOptionのNoneとSome利用でnull安全性が保証
データが0にならならNonZeroを使えばNone時に0が使われて余分なメモリ消費もないしな

**デフォルトの名無しさん** · 2023/03/21(火) 14:39:43.43

隔離スレでやれ
https://mevius.5ch.net/test/read.cgi/tech/1677286186/

**デフォルトの名無しさん** · 2023/03/21(火) 14:40:28.73

>>238
そこを出発点として考える場合でも
filter_map(|opt| opt.map(f))
↓　Optionのままmapしても剥がしてからmapしても同じ
filter_map(|opt| opt).map(f)
↓　Optionに対して恒等関数になってるのでflattenと同じ
flatten().map(f)
と辿り着く

**デフォルトの名無しさん** · 2023/03/21(火) 17:23:17.80

>>247
自分は途中のイテレータ減らしたい派だから一番上で落ち着いてしまう
ラムダ式減らすなら下だろうけどfilter_mapが便利すぎてね…

**デフォルトの名無しさん** · 2023/03/21(火) 18:14:49.79

>>244
Optionは常に値の有無を表している
filter_mapも値の有無を残存判定に用いている
Optionの意味が変わることはない

**デフォルトの名無しさん** · 2023/03/21(火) 19:05:07.54

>>243
いかにも競プロっぽい考え方だね
現実のプログラムでは最低でも(K, V)で管理するから計算対象の値だけを素のOption配列で管理したりしないよ

**デフォルトの名無しさん** · 2023/03/21(火) 19:18:56.96

>>250
インデックス値で管理できるものま無駄なコストがかかるハッシュマップでを用いる気軽な連想配列な考えこそコスト無視のスクリプト言語な考えだよ
インデックス値で管理できるものはRustでは配列かVecを使う

**デフォルトの名無しさん** · 2023/03/21(火) 21:39:30.39

HashMap<K, V>はhash計算コストに加えてkey比較コストがhash衝突回数の分かかるからなー
indexになれる値があって上限が許容されるならVecが有利

**デフォルトの名無しさん** · 2023/03/21(火) 23:56:44.92

>>250が経験不足と知識不足で知らなかったんでしょ

**デフォルトの名無しさん** · 2023/03/22(水) 13:00:26.42

>>251
おいおいなんで急にハッシュマップが出てくるんだよ
そんなんで大丈夫か？

Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの
現実的かつ具体的なユースケースで考えような

**デフォルトの名無しさん** · 2023/03/22(水) 18:31:25.27

ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない

**デフォルトの名無しさん** · 2023/03/22(水) 21:00:04.56

うちも値域が限定されてる離散値はArrayかVec<Option<T>>使う

**デフォルトの名無しさん** · 2023/03/22(水) 21:30:41.78

マニュアルに書いてるような内容をやたら饒舌に語るとChatGPT感出るね

**デフォルトの名無しさん** · 2023/03/22(水) 21:32:36.00

>>255
>ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない
その場合でもTは(u64, K, V)

**デフォルトの名無しさん** · 2023/03/22(水) 21:36:57.10

Vec<Optionは普通に使うぞ
今書いてる部分と似たようなことをしてるregexのソースを見たらVec<Option使ってる
普通そうなるよな

**デフォルトの名無しさん** · 2023/03/22(水) 22:15:33.42

>>257
まるで知能は互角で内容だけが違うみたいな言い方だが
知能の差を見せつければいいだけだよ

**デフォルトの名無しさん** · 2023/03/22(水) 23:19:58.21

Vec<Option<T>>が使われないなんていう話は誰もしてないのにね
話が通じなくてもう面倒くさ過ぎるわ

**デフォルトの名無しさん** · 2023/03/22(水) 23:35:18.64

たぶん論点はfilter_mapの話からここ

> vec![None, Some((1, 2)), None, Some((3, 4)), None];みたいなのはこれがすでに入力値に対して何かしら関数適用した結果なんだよね

> Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの

でもこの主張は間違っていて
疎なデータ構造ならいきなりVec<Option<T>>が現れる
初期値オールNoneから飛び飛びにSome化していく
そのVec<Option<T>>は何度も使うからのイテレータ処理の一時的に現れるものでもない

**デフォルトの名無しさん** · 2023/03/23(木) 00:27:50.25

構うから暴れるんすよ

**デフォルトの名無しさん** · 2023/03/23(木) 07:45:41.23

グラフ構造でVec<Option<usize>>使うこともある
さらにインデックス自体のマッピングにも使われたり
// Maps old index to new index. None if not yet visited.
let mut remap: Vec<Option<usize>> = vec![None; self.nodes.len()];

**デフォルトの名無しさん** · 2023/03/23(木) 08:16:41.69

公式ドキュメントとchatgpt
これだけあれば全て滅びる

**デフォルトの名無しさん** · 2023/03/25(土) 10:51:05.32

人間があれやこれやするよりも
全部 AI 翻訳に任せりゃインジャネーノ

**デフォルトの名無しさん** · 2023/03/27(月) 10:33:42.84

>>263
本当にそうだったね

**デフォルトの名無しさん** · 2023/03/27(月) 13:18:10.65

そのうち
課題を見つける能力
課題を提起する能力
がメインとなるんやろな
1人会社が当たり前になりそう

**デフォルトの名無しさん** · 2023/03/27(月) 17:47:50.73

>>268
今までもそうだったけど気づいてない人が多かったというだけ
解けることが事前にわかってる問題を与えられて解くだけの人は今までも価格競争にさらされ段階的に置き換えられてきた

機械学習による変化は機械に解かせることのできる問題の抽象度が上がったこと

**デフォルトの名無しさん** · 2023/03/30(木) 21:28:14.05

samタレットを壊されないかつ迎撃もできる状態で設置する方法ってない？
拠点屋根に四台設置してんだけどログインする度に毎回壊されてるわ

**デフォルトの名無しさん** · 2023/03/30(木) 21:34:58.46

ごめんスレ間違えた

**デフォルトの名無しさん** · 2023/03/31(金) 12:09:07.07

それはrustだろ？ここはrustスレ。間違えるなよ

**デフォルトの名無しさん** · 2023/04/01(土) 04:03:16.63

Interface 2023年5月号
550号特別企画　2大特集　Linuxでも正式サポート，組み込みや車載で注目を集める　質実剛健 Rust言語
3月25日発売 (定価 1,200円＋税)

第1特集：C言語と比べて理解する
第2特集：マイコンで動くフル機能Rust
特別付録：初めてのRustプログラミング
新連載：毎号実験！自律移動ロボット

**デフォルトの名無しさん** · 2023/04/01(土) 16:12:14.56

>>273
面白そうだな。組み込みだと実装依存のCコードがまかり通っていたりするからな

**デフォルトの名無しさん** · 2023/04/02(日) 17:52:37.39

interface読んでる連中には難しいんじゃないの？

**デフォルトの名無しさん** · 2023/04/02(日) 18:01:44.10

むしろこれを機に組み込みの勉強でも始めてみようかしら

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

>>273
本屋で見てきた。個人的にめぼしい解説はCMSIS-DAPくらいで
大体The Embedded Rust Bookで十分かな

**デフォルトの名無しさん** · 2023/04/02(日) 19:09:06.81

組み込みだったらmrubyだよね
しらんけど

**デフォルトの名無しさん** · 2023/04/03(月) 00:25:42.34

そのうちrust謹製の組み込み OS とか出てくるんじゃねえの

**デフォルトの名無しさん** · 2023/04/03(月) 00:53:16.98

>>279
Google が KataOS を発表してる。今は CantripOS と改名してるっぽいな。
どこまで本気なのかよくわからんけどコードは Github に有るから見物してみたらいいんじゃない？

**デフォルトの名無しさん** · 2023/04/03(月) 09:12:06.30

組み込み分野を目指す学生はPythonばっかり
これを機にRustやCやC++にも目を向けて欲しい
組み込み分野の実務でPythonはつぶしがきかない

**デフォルトの名無しさん** · 2023/04/03(月) 11:15:42.36

組み込みでPythonとか使うのか
一番親和性の感じられない組み合わせやな

**デフォルトの名無しさん** · 2023/04/03(月) 11:32:22.07

ラズパイでしょ

**デフォルトの名無しさん** · 2023/04/03(月) 11:39:22.47

ラズパイは組み込みじゃないだろｗ
組み込み向けだと MicroPython とかあった気がするけど使われてるのかねぇ

**デフォルトの名無しさん** · 2023/04/03(月) 11:55:49.94

ラズパイはLinux系OSが動いていてX Windowを立ち上げてデスクトップPCにすることも可能な環境
昔からからの組み込みが指すのはOSがないもしくは簡易なものしかない環境でありそこでPythonは使われない

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

組み込みかどうかと言うより
ミッションクリティカルかどうかと言ったほうが正確か