プログラミング言語 Rust 4【ワッチョイ】
Mozilla発のプログラミング言語「Rust」のスレです ■公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust ■ワッチョイ スレ建て時、一行目に !extend:on:vvvvv:1000:512 を入れること ■派生元スレ プログラミング言語 Rust 4 https://mevius.5ch.net/test/read.cgi/tech/1507970294/ VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured does not live longエラー関係は自分が思ってるより広い視点で見た方が解決するんじゃないかなあ Hito.konomi_no_mochiは参照なんだから、参照元としてVec<Mochi<'a>>を保持しないと駄目なんじゃね? =>mochiがMapになってて分かりにくい =>とりあえずcollectさせてVec<Mochi>持ったら動いた みたいな。 https://play.rust-lang.org/?gist=6c9947e3584f1feb5bb14f07d27aa9c7& ;version=stable 多分、頭の良い人ならもっと綺麗な説明と解法があるんだろうけど >>92 ありがとうございます 仮引数mのライフタイムはmain関数が抜けるまでだから通るということで合っていますか またVecではなくIterator::Mapだと駄目な理由は、Iterator::Mapはcollectされるまでクロージャが実行されないから…とかでしょうか >>93 仮引数mのライフタイムはクロージャ内なのは変わらないよ。>>92 は仮引数を参照じゃなく消費してるから通る(>>92 の&mじゃなくてmで良い) クロージャが実行されないから、ではなく、mochiの値が消費されてるのにその参照を持たせようとしてるから駄目 試しに>>91 のコードでmochi.map(|m| { 0 })とか書いて、mochiをprintln!に渡してみようとすると怒られるよ。もう使ってるって。 そこらへんの細かいルールを覚えるの大変だし、コンパイラもまだ分かりやすいエラーメッセージ吐いてくれないから、 ・参照を使うときは、参照元をちゃんと生かしておくこと ・参照を使った構造体は、元の値を修飾(見方を変える、新しい機能を持たせる等)するようなパターンに限定すること を守るようにした方がいいよ >>94 「消費したものの参照を持たせるのは駄目」と「消費しているから通る」はそれぞれはわかる気がするのですが、両方となると… 前者の「消費したもの」と後者(main関数中生き続けるMochiのベクトル)は別物だと思うのですが、 前者で駄目な理由は関数中生き続けるMochiがない(mapを呼び出しただけでは駄目)ということですか? 「消費されるので通る」じゃ言葉足らずでした。「参照じゃなくmoveして延命している」の方が通じるかも >>91 のコードを整理すると 1. HitoはMochiの参照を持ってるから、Hitoが有効なスコープ中はMochiも有効じゃないといけない 2. mochiはinto_iterで作られてるからMochi型を吐き出す、けど所有はしない 3. なのにmochizukiはmochi.map()で各要素への参照しか持たない 4. mochiから吐き出されたMochiの受け皿が無いんでエラーになる これを解決するには 1を変えてHitoがMochiを所有するようにデータ構造を変える 2で作られたMochi型の値をしっかり保持する変数を用意する の2種類くらいしか思いつかん。 Does Not Live Longエラーはライフタイムがどうのこうのと小手先で弄るより、 値の所有者を明快にしたり、データ構造を見直してみると案外素直に直せるのが経験則。 >>96 loop{ let (a, cond): (&str, bool) = get_too_many_str(); let m = Mochi{aji: a}; let h = Hito {m : &m}; if(cond){ break; } } // ここでhのvecが欲しい この場合は、ムーブする(ループより長いライフライムの)変数がないので1の手法しかないということになりますか? そこそこでかい文字列を扱っているので気を使っていたのですが、この場合Stringにすべきでしょうか 大きい文字列を扱うから参照にしたいってのは普通にあるし分かるけど Hitoが&MochiでなくMochiをメンバに持つようになっても文字列のコピーは行われないよ 自分なら>>97 のget_too_many_str()が返す&strの元を誰が保持するのかをまず気にする そこをしっかり把握してれば文字列のコピーは最低限になるはずだから >>97 んー、自分なら そこだけに使うMochiCow型作ってでも ajiの型をCowにして凌ぐかな &strの元もloop内の変数が持っています hのvecを作るにはコピーは避けられないようですね… &strからStringに変えたところhvec.push(h)してもエラーにはなりませんでしたが、 スコープを抜けたはずの変数が使える理由ってどこかに書いていますか? そりゃloop内の変数hから、loop外のhvecに所有権が移動したから 頭の中に入れておける物なんて極わずかだし、場当たり的にdoes not live longエラーに対処するのは大変なので、 ・値の所有者はどの変数であるべきか ・データ構造はどうあるべきか という観点だけ念頭にいれて、「性能を稼ぐために参照を使おう」って考えを一旦外すとスッキリするよ まともな話題はslackいっちゃうのかな。 匿名で喋りたいのはアンチ向きか 別にアンチって訳じゃないけど、コンパイルが遅すぎる(特に最適化掛けた場合に)のはどうかと思う。 実行が速くてもその生成に時間が掛かれば無意味でしょう……。 >>108 Rustで組んだ新Firefoxの動作が2倍ほど速くなったのは無意味? まあコンパイルは遅いわな。 ていうかcargoの仕組みが問題なだけか? rustcで単一ファイルだけコンパイルすると結構速いなと思った cargoって警告無視のオプション(-Awarning)の有無でも一からビルドしようとしたりちょくちょくお粗末 なんかRustってテスト用と製品用で別々の最適化を施せるんじゃなかったっけ。 俺は自分の為だけにRustを使ってるのであまり気にしたことがないが。 確実にどんな人でも可能なネットで稼げる情報とか 念のためにのせておきます グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 C717P rustを始めたんだけど 分かりそうで分からなくて イライラする なんだこの言語 他の言語の経験にもよるけど 3000行ほど書けば慣れるよ(適当 actix_webでちょちょいとwebサービス作ろうと思っただけなんだが externとuseみたいに、なんで同じようなものが2つ有るのとか trait?、インプリすればいいだけならなんでこんな名前なんだとか 察するにJava経験者かね externは外部ライブラリのモジュールを参照する宣言 modは自身のフォルダ以下のモジュールを参照する宣言 useはモジュールの要素(Struct or Trait)を取り込む宣言 pub use self::MyStruct; // 要素をexportしたり use std::io::Error as IOError; // as で別名つけたり use super::Result; // 上位の型を取り込んだり(mod.rs以外からだと同一フォルダのmod.rsを見にいくので注意) 肝はselfとsuperを使いこなすことかと このあたりリファレンスに書いてあるんで落ち着いて読んでもらえばいいけど インプリについては、Trait = Interface(Java)の理解でそれほど差し支えない気もするけど (定数は同じ階層のmoduleに移す) AssosiatedTypeがあるように"Traitはコンパイル時に解決できる"ものってのを 意識してればその内に腑に落ちるんじゃないかな ただこんなこと言うと 「RustのTraitは厳密なtraitじゃない論争」(Wikipedia参照)が始まっちゃうかもしれないので ゆるく受け流してほしいところ extern/use周りをrefineする話ってどうなった? チュートリアルの和訳のところを読んでいるけど 誰が訳したんだろう。。。 extern crateは、includeとかload libraryぐらいの意味だと思えばいいと思うが、 「え、それ、Cargo.tomlにもう書いたやん」って思うのは当然の感覚だな しばらくしたら言語仕様変わりそうだなあこれ 勉強していくべきなのかどうか迷う 仕様の改定はc++のようにコンパイラのリリースとは別に2〜3年毎に定めることになってる 将来のコンパイラでも古い仕様を選択して使えるはず どんな言語でも利用者多ければライブラリーのトレンド変わっていって学び直しはあるし 言語仕様の変更だけ特別視する理由が分からん ver1.0になったし、firefoxに200kstepのソースがあるから始めるなら今でしょ ruby1.8から1.9とか python2から3の変更とか 嫌じゃん 言語もライブラリも混在してぐちゃぐちゃ >>124 和訳は最新に追いついていないと思います、公式英文を確認したほうがいい Rustの場合仕様変更の影響を受ける記述はコンパイラがwarning(とsuggestion)出してくれるみたいだし むしろライブラリのアップデートより楽なんじゃないかな やりたいことをするのに1日使って50%しかできなかった 自分には無理だこの言語 ここにまともなRustユーザいないのは年寄りしかいないからなのかなぁ slackかtwitterでコミュニケーションとれるので5chへ書き込みたい事情があまりない >>138 おすすめのハッシュタグはなんでしょうか? もっとメジャーになってslackが荒れて来たらここもワンちゃん slackで発言できないアンチにしか存在価値がないのかぁ つまり変な人でもスレに繰るなら、山の賑わい人気の証ってことね Vec内のアイテムを複数条件やand or等をユーザに指定させてフィルタリングをしたいのですが 無理にでもSQL使うべきでしょうか ユーザってのはどういうレイヤの話をしてるの?もう少し具体的に書かないと意味不明 values.iter().filter(hoge).filter(fuga).filter(piyo) フィルターを何度がけすると型がやばそう 調べてみるとfiltersというクレートがありました いやじゃ、いやじゃ、Eclipseなんぞ使いとうない みんなどんな環境で書いてるの?今はvscode使ってるんだけどrlsがあまりに不安定すぎてストレスが… emacs + flycheck racerは重すぎるんでOFFにしてる 日本語の発音ってかイントネーションはみんなどっち? ラスト(ミファファ=スタバ) ラスト(ミドド=ベスト(着る方)) Rustの型って何を言ってるのか良う分からないくらい一気に複雑になるんだけど、改善の兆しってある? filter(|x| ...).map.(|x| ...)ってやると戻り値がMap<Filter<...>>みたいに、情報量がほぼ増えないのに型の表記だけが増えてくのが見づらくてしゃあないんだが 「ここを関数に切り出しておきたい」ってのも難しくね? impl Traitあるだろって言われるけど、自分ひとりでできた試しが無い >>173 .filter(|x| ...).map.(|x| …)とやったら ざっくり言うと戻り値はIterator<Item=T>でowned, shared reference, mutable referenceの3種類 Map<Filter<...>>とかの詳細な型を知りたいと思うことは基本ないからそこまで困らない デコレータとかコンポジション的なものとして理解しとけばいいと思う 関数に切り出すのはGC言語と比べると難しい どの値の所有権をどの呼び出しレイヤーで保持すべきかを整理しながらリファクタリングする必要がある ただある程度パターンがあるからそれが理解できるとそこまで難しくはない >>174 標準ライブラリでiteratorのメソッドならそうなんだろうな、って他言語でも溜め込んだ知識で何とかなるけどさ、 例えばwarpっていうWebフレームワークはリクエストの解決にfilterを使ってるんだけど、 https://docs.rs/warp/latest/warp/filters/index.html ↑ここからたどって、例えばリクエストのパスにマッチするフィルタを作成するwarp::filters::pathってのがあるんだけど、 こいつの戻り値が独自型のExactってやつなのね warp作ってる人はここに様々な条件を追加できるようにしているんだけど、pathの戻り値にどう組み合わせられるかってのをどう探せるんだろっていつもなってる 他のcrateも、単機能で目的果たせるライブラリならまだいいけど、高階関数で機能組み合わせてねってやつはrustdoc見ても意味が分からなくなってる >>175 ExactがFilterだと分かれば別のFilterを組み合わせられることはわかるでしょ? warpのFilterシステムを理解させるための解説ドキュメントが不足してるのと 他で類似の仕組みをあまり経験したことがないのが理由なんじゃないのかな? 型が入れ子の形でチェインされてる状態に慣れてないから それがわかりにくさの原因のように感じるかもしれないけど JavaやgoのReader/Writerみたいにデコレータ的に型を重ねていくのはそんな特殊なことじゃないよ iterator系の処理はどんな言語でもやりすぎると意味不明なんでいい単位で説明変数や関数に切り出すのは大事だよ。 関数単位で切り出す場合はimpl TraitやBox<dyn Trait>使った方が良いと思う 実装の詳細が型として露出してしまうのはよろしくないし 何より長い型を書き下すのはめんどくさい >>176 いやExactがFilterかどうかが分からないんだ。自信が無い https://docs.rs/warp/latest/warp/filters/path/struct.Exact.html https://docs.rs/warp/latest/warp/trait.Filter.html ↑2つを見ても、ExactがFilterをimplしているとは書いてないんだ 知ってたらマジで教えてほしいんだが、どこ見ればいいの? >>178 そう思うのは人情だが、じゃあどういう型の関数にすればいいのかって話 ググらずに分かる?俺は分からなかった >>179 非公開の(だけど実装が漏れている)FilterBaseトレイトを介してFilterを実装してるんだね…… FilterBaseが公開されていればExactのblanket implementationsに出てくるはず 同じことは指摘されているが放置されている模様 https://github.com/seanmonstar/warp/issues/742 もしかして特段に分かりづらい構造だったのかWarp Sealed TraitっていうユーザーにTraitを実装させないための一般的なパターンなんだけど privateなTraitはドキュメントには現れないのでExactがFilterBaseを実装してることを確かめたければソースを見るしかない でも関数や構造体の説明にFilterだよって書いてるんだからまずはそこからじゃないか? path()「Create an exact match path segment Filter.」 Exact「A Filter matching an exact path segment.」 いや型の説明がコメントにしか無いかったら疑うのが基本じゃないか…? 説明にある通りの使い方はできるけど、何故そう使えるのか分からない、となった上での話 前にもちらっと書いたところもそうなんだけど、impl Filterを返す関数のシグネチャも独力だと分からなかったんだよ。もっと情報の少ないクレートでやる必要が出てきたら詰んじゃう [T]と[T; N]があるように strに対するSizedなstr<N>とかできんかね ttps://doc.rust-lang.org/beta/unstable-book/language-features/yeet-expr.html 名前の元ネタがよくわからん >>185 trY Early-ExiT で yeet じゃない? experimental だからわざとクソ命名してそう。 ProviderとDemandってCOMのQueryInterface的な使い方もできるのかな read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる