Rust part16

1 名前：デフォルトの名無しさん mailto:sage [2022/06/27(月) 08:17:03.45 ID:gDlfKP6u.net] 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust Web上の実行環境 https://play.rust-lang.org 日本語の情報 https://rust-jp.rs/ ※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 part15 https://mevius.5ch.net/test/read.cgi/tech/1652347700/ 782 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:42:44.57 ID:KYVSlV2v.net] >>771 ABI安定化するまではFFIでextern "C"は避けられないよ 783 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:53:19.36 ID:wlVyCNVq.net] >>773 そんなことすべきでない 自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト 外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい 784 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:40:33.31 ID:EyovOcQI.net] 双方でマーシャル/アンマーシャルが必要になって無駄だよね 785 名前：デフォルトの名無しさん [2022/09/23(金) 23:55:09.24 ID:9eaiNZZz.net] なるほど 786 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:58:10.15 ID:SxK8BSHj.net] 対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない 他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない 787 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:06:07.91 ID:j2XeJCoN.net] やっぱエアプの複オジはわかってないなぁ 788 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:11:50.36 ID:DaB/WDgt.net] >>774 pubなitemのABIに最適化関係ある？ なんかと混同してない？ 789 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:14:18.76 ID:DaB/WDgt.net] もしかして repr(Rust) のこと言ってる？ 790 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 03:05:40.90 ID:ugWjDAH5.net] Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう 結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう 791 名前：デフォルトの名無しさん [2022/09/24(土) 08:50:49.84 ID:pfcr5AFZ.net] C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？ 792 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:11:44.18 ID:DaB/WDgt.net] >>781 dylibの場合pubは大いに関係あるよ 793 名前：デフォルトの名無しさん [2022/09/24(土) 09:15:16.80 ID:WR9fIR0K.net] ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ 794 名前：デフォルトの名無しさん [2022/09/24(土) 09:26:53.29 ID:rPP8Qygy.net] >>782 名前をプログラマが決められるからだよ 795 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:44:37.12 ID:BCuennz9.net] >>782 むしろCは決まってるの？ 決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな 796 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 10:38:04.73 ID:2HWwrIyG.net] 近年になって作られた高速リンカ mold の作者の話でも、 文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。 C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、 結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が 解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。 797 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:00:33.46 ID:DaB/WDgt.net] CはCPUベンダーが呼び出し規約を文書化してるよ moldの話はELFやリンクに関連する話では 確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う 798 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:33:36.58 ID:FWSMvJVe.net] AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？ >>786 呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ 799 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 13:14:15.81 ID:DaB/WDgt.net] >>789 そこでいう実装依存ってプラットフォームごとの差違のこと？ それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？ 800 名前：デフォルトの名無しさん [2022/09/24(土) 14:25:21.27 ID:PoJJisuz.net] cdeclとかstdcallみたいなやつ？ 801 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 16:06:51.67 ID:2HWwrIyG.net] >>791 その段階ではあまり曖昧さはない。 リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、 その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。 アーキテクチャによって扱いを変える必要がある場合もあるし。 802 名前：デフォルトの名無しさん [2022/09/24(土) 16:24:43.84 ID:PoJJisuz.net] >>792 コンパイラがリンカに渡す情報って統一規格があるの？ 803 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 17:05:25.99 ID:7d8zqodE.net] >>793 別に統一されちゃいないがELFとかPEとか 804 名前：デフォルトの名無しさん [2022/09/24(土) 17:10:20.79 ID:GMpouZpq.net] じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？ 805 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [[ここ壊れてます] .net] >>795 ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。 ただ現実には全てが正しく実装されているわけではなく、 場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。 仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。 そういう歴史的負債がどんどん積み重なってわけわからんようになる。 806 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 19:08:36.35 ID:eDCmZTMq.net] ARMの規約 https://github.com/ARM-software/abi-aa 807 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 22:13:22.85 ID:DaB/WDgt.net] 元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ LLVMがよしなにやってくれるのでは 808 名前：デフォルトの名無しさん [2022/09/24(土) 22:29:32.09 ID:GMpouZpq.net] ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？ 809 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 08:24:33.85 ID:j3K9KjV7.net] Option<NoneZeroUsize>などを使えば IDやカウンタなどの用途でOption<usize>などを使っていたものを 半分のメモリサイズで済むようになるの？ 810 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 11:42:14.43 ID:sQFmQmse.net] >>799 任せてください。符号ビット省略しておきますね 811 名前：デフォルトの名無しさん [2022/09/25(日) 15:32:52.52 ID:F2Viqk5M.net] Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない 812 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:24:00.83 ID:xalR35FT.net] Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに Microsoftはダメなの？ 813 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:34:47.30 ID:4B3i10Bx.net] try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ 814 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:57:47.12 ID:6lgwXJxi.net] 言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは 815 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:09:02.84 ID:6wI0gbs/.net] 正直LinuxにRustなんて辞めればいいのに・・・ 816 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:14:08.03 ID:Td47G6We.net] Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの 作り方の解説とかどっかにある？例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定 関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし 817 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:21:16.44 ID:xalR35FT.net] テストがすごいのはSQLite 818 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>803 別に独自拡張とか入れてないだろ コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない 819 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 19:57:21.62 ID:6lgwXJxi.net] >>806 なんかまずいことでもあるの？ 820 名前：デフォルトの名無しさん [2022/09/25(日) 19:59:47.96 ID:Rxhh3DJ9.net] >>810 迷走と凋落、そして黒歴史化。 821 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:07:26.82 ID:58piYD8Z.net] >>807 メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない 822 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:26:59.51 ID:Td47G6We.net] >>812 条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした 関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい で、テストを作ろうとしたけどどうしようか悩み中 823 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:37:27.14 ID:lhW/fB5K.net] そういうのは呼び出し側の単体でええんちゃうの 824 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:09:49.29 ID:j1+dHWho.net] >>807 歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。 対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。 歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。 825 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:31:04.61 ID:Td47G6We.net] >>814 中間コンポーネントの単体テストって普通どうやるんだろ 後段のコンポーネントを切り離してテストするのか？繋げたままテストするのか？ 切り離せるようにするとその部分にバグが入り込む余地が生まれるし >>815 歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため △△のような実装がベターだみたいなのが沢山あるからねぇ そしてこの手の情報はググっても網羅するのが難しい 826 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:09.44 ID:6lgwXJxi.net] >>811 Linux側にメリットがないと言ってる？ 827 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:47.84 ID:PDKGWlWe.net] >>816 > 中間コンポーネントの単体テストって普通どうやるんだろ 中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする たいていのテストツールではモックの呼び出し回数のテストができる 828 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:53:52.45 ID:j1+dHWho.net] >>816 JavaみたいにDIが発展しているタイプの言語だと中間コンポーネント� 829 名前：ｪ呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。 けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。 モジュール設計の考え方が変わるからかな？ [] [ここ壊れてます] 830 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 22:41:02.05 ID:Td47G6We.net] 今作っているのだとこんな感じかな？ 関数C(データの前処理、処理単位への分割) ↓ 関数B(処理全体の制御)→関数A'(処理1-2) ↓ 関数A(処理1-1) >>818,819 その場合モックへ切り替える機構はどうするんだろ そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか 831 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:07:36.94 ID:h/WE7ZWH.net] >>820 すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね 832 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:33:03.55 ID:TCGzsvbI.net] mockall使うとか 833 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:28:19.26 ID:p/pWEmYs.net] cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの？ 834 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:47:39.41 ID:h/WE7ZWH.net] >>823 >>820 > その場合モックへ切り替える機構はどうするんだろ に答えてやってくれ 835 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:21:24.42 ID:kI3cAlPQ.net] モックやスタブは別モジュール化しておいて mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの？ 836 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:47.69 ID:V9yeC/LF.net] あと#[cfg(test)]でそれをuse そして#[cfg(not(test))]で本物use 837 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:51.25 ID:i/jndsoD.net] 他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな 説明が面倒だ 838 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:38:20.09 ID:V9yeC/LF.net] >>827 テスト以外の開発の話でも フレームワークに依存してやってる人は 単純なこと含めて本質的なことを理解してない人が多く フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける 839 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:10:39.16 ID:qW/k82Qg.net] cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ 何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ という思想の言語だと思っているんだが違うのかな 840 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:41:35.64 ID:w5YNQb64.net] >>829 #ifは使わないし cfg(test)はテスト分離のため必須でしょ どんな環境でも魔法は無いよ 841 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 23:33:07.51 ID:h/WE7ZWH.net] >>829 cfg使わないで済むいい方法があるなら書いてよ... 842 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 01:17:35.37 ID:OwORQ6vn.net] mod tests に cfg(test) は必要だとして 依存性の注入にはtrait使えって事なのでは 843 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 07:51:04.95 ID:f9SEu4pT.net] traitで置き換え可能にするのが面倒というのはありそうだな。 844 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 08:15:53.87 ID:SBVoZTui.net] AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな 845 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 11:05:22.42 ID:OwORQ6vn.net] size_tが64bitだからでは 846 名前：はちみつ餃子 mailto:sage [2022/09/27(火) 12:28:55.13 ID:ozjafOA0.net] >>834 usize はポインタのサイズということになっている。 847 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] >>831 単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前 そうしないとそもそも単体テストにならないじゃん わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ そういうことができるようにあらかじめコード設計しておかないといけないがな 考えてなかったならリファクタが必要 848 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:48:22.41 ID:J8MleXan.net] そんなフワフワした説明されても... 849 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:51:56.44 ID:AWnlNGZp.net] 本物と異なり決まった値を返す送信元スタブと 本物と異なりassertだけする送信先モックを mod testsの中では本物の代わりにuseするだけだよね 入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね 850 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:44:24.76 ID:JQpGo85s.net] >>839 useしたモックをどうやって注入すんの 関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、 genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは それともmod testsの外もcfgで置き換えると言っている？ 851 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:48:00.37 ID:JQpGo85s.net] 要は use imp::Foo; fn target(foo: Foo) {} がテスト対象だとして mod tests { use mock::Foo; #[test] fn test() { target(Foo::new()); } } してもコンパイル通らないよね targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では 852 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 07:20:15.72 ID:1i04Jlqk.net] traitが無い言語では無理ってこと？？ 853 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 11:35:17.56 ID:RLf9Yg7w.net] >>842 他の言語は他のやり方でやってるだけだろ 854 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 01:43:05.00 ID:xXycU9Ev.net] u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。 しかしエラーになります。 struct Code(u32); impl<T: Into<u32>> From<T> for Code { fn from(x: T) -> Self { Code(x.into()) } } impl From<Code> for u32 { fn from(Code(x): Code) -> Self { x } } 結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ) の定義と衝突しているという理屈は理解しているのですが、 問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように うまく制約を付ける方法は思いつきません。 そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて 「自分自身だけ除外するような制約」を上手いこと表現できませんかね？ 855 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:16:48.63 ID:zId7dOnm.net] 無い 856 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:20:01.39 ID:7xp1eqla.net] そっかー 857 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:40:21.97 ID:U5dWXlr2.net] そういうのはIntoCodeみたいな感じで別トレイトにすることが多い気がする https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html 858 名前：デフォルトの名無しさん [2022/09/30(金) 02:17:04.59 ID:Yj/X+hjS.net] 初歩的なことですまんけどさ メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの？ let asdf = self.asdf; 859 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 10:23:40.27 ID:1sTGpNyR.net] 名前を短くする目的が99パー 860 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 11:00:13.39 ID:tNhbOFxw.net] クロージャーで構造体のフィールドにアクセスすると構造体ごとムーブしちゃうんでそれ対策じゃないかな 2021で対策されたからどんどん減ってくだろうけど https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ebea0bd9611104e7a90eb8dfcb9899c9 861 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 12:43:57.87 ID:NYKsqXq4.net] 書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある let Foo { foo, bar. baz } = self; としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる 構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる 862 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 13:52:13.77 ID:yzoXDHK/.net] >>851 なんかすごくモヤモヤする 863 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:15:24.65 ID:oHn8O8ll.net] 本人は俺ってスゲー、天才やん！ って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ？バカじゃねーの ってなるパターンかと まあこういう工夫をすること自体は悪くない 864 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:42:00.50 ID:M1og6e+j.net] フィールドそれぞれに処理をするシチュエーションがわからない 865 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:50:06.85 ID:temvUu5a.net] >>851 俺もそのdestructuring assignment自体は使いまくる しかし目的が漏れチェックとは違うのでこうだな let Self { foo, bar, .. } = self; 866 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:55:47.39 ID:t/wNXSJY.net] >>851 これいいな 867 名前：デフォルトの名無しさん [2022/09/30(金) 15:59:33.74 ID:XmkFmofe.net] こうやって自己満足の意味不明なコードが量産されていく 868 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 16:19:08.34 ID:GH/ZHf2N.net] 全フィールド舐めるのが重要な処理ってシリアライズとかだろうか そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う シリアライズしたいだけならserde使って#[derive(Serialize)] これも結局proc_macroだわな 869 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 17:36:27.38 ID:NYKsqXq4.net] コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、 それらを処理するところで分割代入してローカル変数にして処理してる 人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている 好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ 870 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:29:47.97 ID:hYwRxeDD.net] >>844 impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。 Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。 まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。 871 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:38:45.63 ID:6voBA5Ft.net] &(T, U)と(&T, &U)って等価ですか？ 872 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 05:47:36.69 ID:6w1pI6Co.net] 等価ではありません 873 名前：デフォルトの名無しさん [[ここ壊れてます] .net] アドレスを考えれば明白に別物 一方で let t = (123, "abc"); let (x, y) = &t; と自動マッチングしてくれて &t の型は &(i32, &str) x の型は &i32 y の型は &&str となる つまり&(T, U)が(&T, &U)に分割代入される 874 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 10:11:02.15 ID:vdaryILR.net] test 875 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 22:39:32.97 ID:zgM1XF6F.net] amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど r14、r15よりr13を空けておく理由がなにかあるのかな 876 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 23:46:41.15 ID:cMmfYMlm.net] >>865 そんな不吉なレジスタなんか使うな！ 877 名前：デフォルトの名無しさん [2022/10/04(火) 00:38:55.95 ID:1GTeu6AF.net] うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか 伝わりにくいかもしれませんけど 878 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 00:52:50.22 ID:4fgdKnMe.net] そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは！ 879 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] 作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと 880 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net] Rustはデータ構造を最初に設計しないといけないというのはあるな C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど 雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう 881 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 08:55:50.45 ID:fDq9dWrD.net] C系は良くも悪くも動いてしまうんよな そんで知らぬ間に副作用まみれになっている 882 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 09:10:45.14 ID:9SKodj4D.net] >>867 慣れの問題も大きいのでは

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef