プログラミング言語 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 申し訳ありません 途中送信してしまいました コードをplaygroundに移しました https://play.rust-lang.org/?gist=10bd65d0bfaf8b5117399b18bd8eb0d2 VecのDisplay::fmtをカスタマイズしたくて上の様にMyTypeを作成したのですが Vecのメソッド委譲するためのコードを手書きする作業が煩雑になって困っています 何か上手い回避策は無いでしょうか? >>9 私も初心者で分からないですが最終的に何がしたいんでしょうか? >>10 レスどうもです Vec(他標準 struct)のDisplay::fmt出力をカスタマイズしたいんです 例えば ・要素数が多い場合、最初の数個を出力して残りを省略するとか ・要素の出力が長くなる場合、適当なところで改行するとか ・インデントを受け付けてネストしてる場合は改行とインデントで整形するとか その上でVecのインターフェースをそのまま使いたいんですが >>9 のように新規の構造体を作る場合 手書きで委譲せねばならず どうにか上手く出来ないもんかな……と >>11 その用途ならVecに別な名前のメソッドを直接implしちゃってそっち呼び出せばいいような気がしたんですが println!("{}", v.my_fmt()); みたいに >>12 ごもっともです self.0に委譲するマクロが上手く書けなかった経験があり それに引きずられて本質を見失ってました コードを整理していったらいけそうな感じになりました https://play.rust-lang.org/?gist=960819f1fb1b5f9988a1c58cab2b1b9e& ;version=stable ありがとうございます >>13 ああ、なるほど Derefは思い至ってませんでした メソッド委譲の解決になりそうで助かります こちらもありがとうございます >>16 の論旨は「MyType<T>は常にVec<T>として扱われても問題ないか?あるならDerefはおすすめしない」だと思うけど、 今回の場合はむしろMyType<T>は特別なことが無い限りVec<T>として使いたいんじゃないの? >>16 読みました 見覚えのあるピンク玉はrust playgroundの中の人でした 「smart_ptrぐらいの同一性がある場合にはDerefが必要だけど strにDeref<Taget = [u8]>が無いように Derefだとやりすぎな場合もあるからdelegate構文欲しいよね」 ってなとこでしょうか strの例は「替わりにas_bytesがあるよ」ということかなと strとsliceとか他のライブラリを眺めた個人的な結論としては has_aならAsRef、is_aならBorrowをimplして受ける関数で使い易くしておくのが Rust的な落とし所なのかなーといった印象です AsRef, Borrow, Derefの使い分けは宣言的にプログラマの裁量に任されてる感じ よくよく考えれば自分のコードにもas_xxx, as_xxx_mutが散見されている現状なので Mytypeにもas_vecを書けばそれでも良かったような気がします >>17 自分のケースの場合はそもそもMyTypeがいらなくなってしまったもので Derefはオーバーパワーかなと思ってます とはいえ smart_ptrのように扱うならDerefが有用ということが 知見として学べたので 大変ありがたかったです >>17 このスレを読んでる人に情報共有してるだけだよ オライリー届いた。 分厚すぎてわろたわ。読むの大変そう。 dyn Traitが入ってしばらくしたらBox<Trait>はdisconになるの? deprecated扱いになって警告を出し次のepochで削除とかだったと思う impl Trait入ったらそもそもほとんど使わなくなるから気にしなくていいのか。 使うケース減るのもそうだけどepochで機能削除する場合はソースコードの変換ツールが提供されるらしい あと古いepochのソースはそのままコンパイルできるらしいから特に対応不要らしい だから新しいepochにしか入っていない機能を使いたいcrateとかでなければ何もしなくても困らないはずだし その場合でも変換ツール通せば簡単に対応できるはず epoch releaseってのはどういうことなんだってばよ? map: BTreeMap<K,V>で、keyが無かったら挿入、あったら格納されてる値vに応じて新しい値new_vに更新するか決めるってやりたいんだけど、 let v = map.entry(key).or_insert(new_v); if ... { *v = new_v; } よりもっと綺麗な書き方ある? https://webassembly.studio/ CやRustでWebAssemblyできるOnlineIDEだそうな Rust Never Sleeps: Community Grows, Eclipse-Based IDE Planned https://adtmag.com/articles/2018/02/01/rust-grows.aspx wasmってまだプリミティブすぎて使い物にならないのかと思ってたけど wasm-bindgen すげえな もうここまでできるのか Rustすごい! takahito takabayashiさんのツイート: "ファミコンのエミュレータをRust / WebAssembly で書き直した https://twitter.com/tatakaba/status/961532612723511296 苦労して書き直しても全然パフォーマンス上がらないのな… ぐうの音もでないほど効果があるユースケースってなんなんだ アルゴリズムが変わらないならそう変わらんのじゃないか 他人のひどいコードならともかく、同じ人が小規模なプログラムを書き直す程度だと特に C/C++からRustへ書き直して速度が上がったって話はあんま聞いたことが無い 速いネイティブライブラリを言語に組み込んでるJuliaとかなら、書き直すだけで速度上がったって話はちらほら pythonだったらnumpy使った方が楽でいいとかも いやだってjavascriptだぜ?アルゴリズムの問題か? c++もそうだがコンパイラに機能を詰め込むってのがそもそも筋が悪い >>48 やっぱりちょっと分からないな。 RustやC++のどの辺がコンパイラに機能を詰め込んでると思うの? ライブラリorツールに任せるってのもどの辺を任せたいのかな? 話がザックリし過ぎて言いたいことがよく分からないんだが。 プリプロセッサマクロのことかな?あとは型システムとかGCのことかな?ライブラリに任せるの意味がよくわからんが… C++はコンパイラの方もだけど標準ライブラリでの機能実現も相応に多くて結果ソースの記述が煩雑になっているのは既知の事実でしょう ライブラリや実装に任せた結果APIの統一が取れなくなって結局細かな仕様策定を余儀なくされたSchemeを見ても銀の弾丸でない事は明らかだよね それに出来る事を増やすという点においてライブラリは有用だけど変数の不変性や型システムのような制限をする事に関してはコンパイラによしなにしてもらうより他ないよ ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ やっとstableでrustfmtできるようになったな >>45 は言語仕様の追加、更新が気に入らないんじゃないかな try!の代わりに?なんて以ての外だ、みたいな?それ以外に思い付かなかったけど 1.0以前に@や~を削除してライブラリにぶん投げた辺りは希望通りな気がする 基本的に電池入りじゃないRustはライブラリやマクロの代わりの言語仕様の追加じゃなく より効率的なバイナリを吐くための言語仕様の追加が多いイメージだけどなぁ、impl Traitとか >>56 あー、そういうこと。?記法は確かに若干違和感あったかもな。 でも実際、あれは便利なんだよなぁ。 File::open(path)?.read_to_string(&mut buf)?みたいに繋げられるから。 try!(try!(File::open(path)).read_to_string(&mut buf))は読みづらい。 かといって、 let mut file = try!(File::open(path)); try!(file.read_to_string(&mut buf)) みたいに2行に分けるのも面倒だし、無駄なローカル変数も出来れば避けたい。 結局、あれが妥当な判断だったと思うけど。 まぁ、stableにする必要あったのか?ってところで賛否両論あるかもね。 box キーワードは何時 stable になるんだ? boxキーワードはどういう時にうれしいのかがわからん 明らかに二行に分けた方が読みやすいわけだが。 新しい機能マンセー厨ってそういう感覚の狂いについて無自覚過ぎんだよね。 俺も違和感はあるけど、多くの人が賛意を出して採用されたんだから >>60 や俺の感覚が狂ってるんじゃね?自身の感覚の狂いって当然ながら無自覚過ぎんよ boxは在り様の総意を取るの面倒だし、目下はBoxで運用できてるしで、いつまでもstableに来なさそう ヒープを多用したい人には文法にあればありがたいんだろうけど、そもそもヒープが好まれんしのう boxっていきなりヒープにメモリ確保されるのが保証されたりするんじゃないの? 今はコンパイラ次第じゃん ironって今メンテされてないのか 最近のweb FWはrocketの方が人気なんかな nightly専用だからまだ手を付けてないんだけど それはInPlaceとかPlacerがあればよくてbox inはただのsyntax sugarでは 分解の方がよほどsyntax sugarじゃないのかいな NightlyのInPlace, Placer使わなくても、Stableの環境でmacro使って実現出来そう boxって名前はBox<T>以外に使う場面で綺麗に見えない place <- exprは代入みたい tokio-coreなくなるんか 一通り組み上がった後の悲しいニュース まじか、ちょっと辛いな 依存してるライブラリも結構あるよね tokio系列のやつってtokioとかtokio-coreとかtokio-ioとかtokio-protoとか複数あってよく分からんのよね tokio-ioのリポジトリにはtokioに移動したからもう使うなって書いてあるし tokio-coreは移動じゃなくて廃止予定って書いてある… tokio-protoはそのまま?tokio-timerとかtokio-serviceとかよく知らんリポジトリもあるし… 誰か各クレートの特徴(役割)と関係性を教えてくれ >>71 あっちは、アンチが立てたキチガイ専用スレだからいいんだよ コミットを追うとtokio-coreはtokioに変わったように見える tokio-core=tokioでtokioの本体 tokio-ioはtokio-coreを使って非同期ioを実装したものだったがしゃらくせえのでtokio-coreに取り込んだのかな tokio-protoはtokio-coreを使ってネットワークプロトコルを実装したものだったがしゃらくせえからtokio-coreに取り込んだのかな つまり tokio = tokio-core + tokio-io + tokio-proto か? [] [[[ [[ [] ][ [] [ ] [] ][]] [[[ [] } tokio-protoとtokio-serviceってtrait宣言が主体のインターフェース定義クレートだったような? 前者はクライアント、後者はサーバに適したインターフェースが定義されてた覚えがある io, timer, cpupoolなんかはユーティリティ機能が実装されてたよな 統合の基準はどこかで議論されたんだろうけど、どこでやってたのかな 【お知らせ】Packt出版より Network Programming with Rust が発売されました。 https://play.rust-lang.org/?gist=cb511b34bc3ffbb43b8589a24156337a& ;version=stable let mut foo = Foo{ a:0, b:0, c:0 }; let aaa = ["5", "432", "3"].iter().flat_map(|i| i.parse::<u32>()).collect::<Vec<_>>(); foo.a = aaa[0]; foo.b = aaa[1]; foo.c = aaa[2]; Rustってこれ以外に書き方ありませんか? tupleでやってみるとleft-hand of expression not validと出ました >>79 大量のフィールドに値を入れるのって 一行一行書くしかありませんか? 一行にしたいなら foo = Foo { a: aaa[0], b: aaa[1], c: aaa[2] }; でも良いだろ。 部分書換なら foo = Foo { a: aaa[0], .. foo }; とかもある。 朗報: ついにウェブプラットフォームでRustが速度性能トップを取る https://www.techempower.com/benchmarks/#section=data-r15& ;hw=ph&test=plaintext なお、JSON操作を伴うとJavaにも劣る模様 ツリー制御が不得意すぎて笑うわ JSON serializationはそんなに悪くないんじゃね?tokio-minihttpで96.2%出てる。 それよりSingle QueryとMultple Queryが遅いのが問題じゃね? serdeでシリアライズだけするぶんにはjavaの1.4倍くらい早かったんだけどなあ(俺調べ) Rust book first editionからの変更知りたいんだけどバージョン差分どこでまとめられてる? >>83 >>89 なんで自分で調べようともしないの? Rust Languageさんのツイート: "Announcing Rust 1.24.1: we had some regressions in 1.24.0, so we've released a patch release. Please check it out! https://t.co/zrItc0qiqD" ; https://twitter.com/rustlang/status/969367994072739841 👀 Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01) Iterator::mapに渡すクロージャ内で、クロージャ内の変数への参照を持つstructを返したい時ってどう対処するのが正解ですか? https://play.rust-lang.org/?gist=a15e0dfa10339570fef5b9225761a9f0& ;version=stable 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倍ほど速くなったのは無意味? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる