[過去ﾛｸﾞ]
Rust part24 (1002ﾚｽ)
Rust part24 http://mevius.5ch.net/test/read.cgi/tech/1716759686/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
2: デフォルトの名無しさん [sage] 2024/05/27(月) 06:42:29.23 ID:T4AFD1f4 Rust The Book (日本語版) https://doc.rust-jp.rs/book-ja/ Rust edition guide (日本語版) https://doc.rust-jp.rs/edition-guide/ Rust by example (日本語版) https://doc.rust-jp.rs/rust-by-example-ja/ Rust cookbook (日本語版) https://uma0317.github.io/rust-cookbook-ja/ Rust API guideline (日本語版) https://sinkuu.github.io/api-guidelines/ Rust nomicon book (日本語版) https://doc.rust-jp.rs/rust-nomicon-ja/ Rust async book (日本語版) https://async-book-ja.netlify.app/ Rust WASM book (日本語版) https://moshg.github.io/rustwasm-book-ja/ Rust embeded book (日本語版) https://tomoyuki-nakabayashi.github.io/book/ Rust enbeded discovery (日本語版) https://tomoyuki-nakabayashi.github.io/discovery/ Rust Design Patterns (日本語版) https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651 https://qiita.com/Yappii_111/items/654717e6a6a980722189 Rust API guideline (日本語版) https://sinkuu.github.io/api-guidelines/ http://mevius.5ch.net/test/read.cgi/tech/1716759686/2
38: デフォルトの名無しさん [sage] 2024/06/03(月) 09:53:26.77 ID:oYPTQzXH >>37 Windows クレートはもうかなり充実してるよ。 メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。 unsafe なのは本質的に unsafe なのでどうしようもないし。 Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。 http://mevius.5ch.net/test/read.cgi/tech/1716759686/38
109: デフォルトの名無しさん [sage] 2024/06/13(木) 21:29:59.05 ID:/G8REiwP RustはC/C++に置き換わるのか？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/109
241: デフォルトの名無しさん [sage] 2024/06/18(火) 12:23:59.59 ID:/B9kzKJY Rustの仕様と実装の分離ができてないと、公式の実装が唯一になるから困る分野があるんだろうね。 Cとかコンパイラいっぱいあるじゃん。 Rustぐらい複雑で成長途上の言語で仕様を文書化して実装を交換可能にするなんて事実上無理っぽいけど、10年後ぐらいには問題でてくるのかもね。 http://mevius.5ch.net/test/read.cgi/tech/1716759686/241
280: デフォルトの名無しさん [sage] 2024/06/20(木) 17:45:56.15 ID:sFnTxIc/ Rustのマクロは全言語の中でも優秀だからね 手続きマクロの強力さと利便性は他では代えがたい 宣言マクロももちろん衛生的(健全)で汚染がない http://mevius.5ch.net/test/read.cgi/tech/1716759686/280
289: デフォルトの名無しさん [sage] 2024/06/20(木) 22:08:57.89 ID:0f6ktMCR paiza.ioでクレートを追加する方法を教えてください https://i.imgur.com/RkQr1Wu.png http://mevius.5ch.net/test/read.cgi/tech/1716759686/289
328: デフォルトの名無しさん [] 2024/06/24(月) 07:45:03.03 ID:m0RxboDo if や case や match や テーブル参照は使わないで (出来れば四則演算のみがベストアンサー) 変換前→変換後 1→2 2→1 3→3 4→10 6→4 8→8 10→6 を行う関数を造ってください さらにその逆関数を造ってください http://mevius.5ch.net/test/read.cgi/tech/1716759686/328
399: デフォルトの名無しさん [sage] 2024/06/27(木) 11:20:07.91 ID:veLj9zg3 よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ 「そんなわけないだろ」って思うんだけど http://mevius.5ch.net/test/read.cgi/tech/1716759686/399
441: デフォルトの名無しさん [] 2024/06/28(金) 09:41:44.10 ID:RD8xbJnt 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ http://mevius.5ch.net/test/read.cgi/tech/1716759686/441
469: デフォルトの名無しさん [sage] 2024/06/29(土) 15:34:20.66 ID:KH8yb7Br それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる Rust特有のリファクタリングしづらさは、あるよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/469
474: デフォルトの名無しさん [sage] 2024/06/29(土) 16:52:22.95 ID:KH8yb7Br >>471 「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる * 追加するライフタイムは既存のライフタイムと同じであるべきか * 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?） それで1つの型がリファクタリングできたところで、 * トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し ここまでのすべての作業に尋常でない集中力が必要になる 繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ 「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、 作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る 「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない 少なくとも自分の頭では作業の段取りを崩すだけだった そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい http://mevius.5ch.net/test/read.cgi/tech/1716759686/474
497: デフォルトの名無しさん [sage] 2024/06/30(日) 10:53:06.05 ID:DQMdIUg4 あえて >>493 で頑張ると https://paiza.io/projects/sk40IXUgPm0k_VgI1wsHBg fn main() { let cwln = |s| { println!("{}", s) }; let g = |(i, line): (usize, &str)| { format!("{:>2}:{}", i + 1, line) }; let f = |file_name: String| { cwln(file_name.clone()); std::fs::read_to_string(file_name).map(|u8b| { u8b.lines().enumerate().map(g).for_each(cwln) }).unwrap() }; std::env::args().skip(1).for_each(f) } http://mevius.5ch.net/test/read.cgi/tech/1716759686/497
534: デフォルトの名無しさん [sage] 2024/07/01(月) 12:59:53.25 ID:irzLgX5l >>525 こう書くとresultがErrの時に返せずここでpanicになってしまう let val = result.unwrap(); f(val) そのためpanicしてもいいとか絶対にErrとならない特殊な場合を除けば unwrapを用いてはダメでmapを使ってこのように書くんだよ result.map(|val| f(val)) ここで本当に関数fを呼ぶだけならresult.map(f)と簡略化できるけど f(val)の部分は式やブロックの可能性もあるので簡略化せずに進めるね これは以下と同等でErr(err)の時に保持してくれている match result { Ok(val) => Ok(f(val)), Err(err) => Err(err), } ちなみにf(val)もResultを返すときは mapの代わりにand_thenがある result.and_then(|val| f(val)) つまり以下の二つは同等 result.map(|val| f(val)) result.and_then(|val| Ok(f(val))) この場合はもちろん簡素なmapを用いるべき http://mevius.5ch.net/test/read.cgi/tech/1716759686/534
607: デフォルトの名無しさん [] 2024/07/07(日) 09:17:14.13 ID:7aG8TPof >>604-605 ありがとうございました。 「継承」って良いからオブジェクト指向言語の機能になっていたのではないんですか？ なんか時代とともに、昔は良いとされていたものが今ではダメになったりするんですか？ なぜそんなに揺らぐのでしょうか？ 言語の設計の学者はぼんくらばかりなんですか？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/607
638: デフォルトの名無しさん [sage] 2024/07/07(日) 23:03:31.83 ID:Eha1J0DV >>633 整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない それと文字列 + 文字列が定義されている言語では 分数 + 整数の定義に必要な関数も継承したくない その関数は文字列と無関係だから http://mevius.5ch.net/test/read.cgi/tech/1716759686/638
657: デフォルトの名無しさん [sage] 2024/07/08(月) 11:27:47.73 ID:Qb4+6aEo 「実装は継承しているけど実装継承ではない」ｗ http://mevius.5ch.net/test/read.cgi/tech/1716759686/657
660: デフォルトの名無しさん [sage] 2024/07/08(月) 13:25:29.85 ID:QAb8fFud 継承の本当の問題は、LSPを満たさない部分型関係を作ってしまいがちということ 他の型の実装に依存するのが良くないというのはDIの話で、直接は関係ない http://mevius.5ch.net/test/read.cgi/tech/1716759686/660
684: デフォルトの名無しさん [sage] 2024/07/09(火) 21:07:20.42 ID:YflJELWV >>683 あるトレイトでpanic2を禁止しようとしました。事前条件(あるいは例外条件)でnopanicとしたかったけど、そんなのは無いのでとりあえずデフォルト実装でpanic禁止にしました。 しかしトレイトユーザーはそんなのお構い無しにunsafe rustでpanicを使います。ついにpanicが発生してシステムダウンしました。 LSPでケアしている問題はRustのTraitを使っている限り発生しないんじゃないんだっけ？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/684
685: デフォルトの名無しさん [sage] 2024/07/09(火) 21:56:05.19 ID:sTXYSGuF Rustのトレイトは優れているため LSPに違反するコード例を作ることができないんだよ もしRustに文句をつけたかったら LSPに違反する二つの型のコード例を作って示してごらん Rustで違反例を作るのは不可能だよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/685
691: デフォルトの名無しさん [] 2024/07/09(火) 22:57:23.83 ID:/lHavWP5 >>685 リスコフの置換原則は設計的な原則だから言語仕様で違反を防ぐことはできないぞ 悪名高い長方形・正方形の問題はトレイトがあっても起こり得る trait Rectangle { fn set_width(&mut self, width: i32); fn set_height(&mut self, height: i32); fn width(&self) -> i32; fn height(&self) -> i32; fn area(&self) -> i32 { self.width() * self.height() } } struct Square { len: i32 } impl Rectangle for Square { fn set_width(&mut self, width: i32) { self.len = width; } fn set_height(&mut self, height: i32) { self.len = width; } fn width(&self) -> i32 { self.len } fn height(&self) -> i32 { self.len } } fn func(x: &mut impl Rectangle) { x.set_width(3); x.set_height(4); // xが長方形であれば以下が成り立つはずだが、Square型を渡された場合に失敗する assert!(x.area() == 12); } http://mevius.5ch.net/test/read.cgi/tech/1716759686/691
721: デフォルトの名無しさん [] 2024/07/10(水) 13:29:52.02 ID:kPG9kWdt >>701 そのやり方がなぜ悪いのか理解できませんので、教えてください。 例えば、C++だと、以下の様にするのも別に悪いやり方ではないような 気がするのですが。 class Number {・・・}; Number add(Number &a, Number &b); Number mul(Number &a, Number &b); class Integer : public Number {・・・}; class Rational : public Number {・・・}; http://mevius.5ch.net/test/read.cgi/tech/1716759686/721
757: デフォルトの名無しさん [sage] 2024/07/11(木) 21:30:58.09 ID:wPVHCKh0 実際のところRustはサーバーサイドで使われてるの？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/757
764: デフォルトの名無しさん [sage] 2024/07/12(金) 00:13:00.93 ID:0qGKBZrU >>753, 754 トレイトの場合はLSPで言うsupertypeやsubtypeになるのは トレイトを利用して作られるimpl Traitやtrait objectの型だよ PartialOrd/PartialEqやFn/FnMut/FnOnceのように supertrait/subtraitの関係にあるやつも便宜的にトレイトで互換性が語られるけど 実際はそれらを利用して作られる型についての話なのと同じなんだよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/764
787: デフォルトの名無しさん [sage] 2024/07/12(金) 22:05:28.85 ID:LuKbokrL >>785 参照カウンタ等がその別口 逆に聞くけど全てを参照カウンタで書かないのはなぜ？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/787
812: デフォルトの名無しさん [sage] 2024/07/13(土) 10:59:18.93 ID:SqKWY/h6 >>767 >>768 >traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため >supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるから どちらも同じ勘違いをしてるよ よく読もうね What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T http://mevius.5ch.net/test/read.cgi/tech/1716759686/812
831: デフォルトの名無しさん [sage] 2024/07/13(土) 15:38:58.70 ID:MYuplL5h >>830 それLSPのどの項目に違反してる？ LSPは振る舞いに関する形式的なものなのでそのような意味論にまでは踏み込んでいないよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/831
897: デフォルトの名無しさん [] 2024/07/19(金) 23:30:11.35 ID:rC6z5NUh >>886 let x; HashMap::<_, _> = vec.try_into()?; >>889 ＋１ http://mevius.5ch.net/test/read.cgi/tech/1716759686/897
903: デフォルトの名無しさん [sage] 2024/07/21(日) 09:43:03.00 ID:QhoywuRk >>901 こういうのが「Rustは学習コストが高い」って言われる原因なんだろうな 答えを知ってる人は判ってても答えを知らない人は判らない 答えを調べるのにコストがかかりすぎる http://mevius.5ch.net/test/read.cgi/tech/1716759686/903
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.230s*