[過去ﾛｸﾞ] Rust part24 (985ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
2(4): 2024/05/27(月)06:42 ID:T4AFD1f4(2/3) AAS
Rust The Book (日本語版)
外部ﾘﾝｸ:doc.rust-jp.rs
Rust edition guide (日本語版)
外部ﾘﾝｸ:doc.rust-jp.rs
Rust by example (日本語版)
外部ﾘﾝｸ:doc.rust-jp.rs
Rust cookbook (日本語版)
外部ﾘﾝｸ:uma0317.github.io
Rust API guideline (日本語版)
外部ﾘﾝｸ:sinkuu.github.io
省15
38(3): 2024/06/03(月)09:53 ID:oYPTQzXH(1/3) AAS
>>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。
Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。
109(5): 2024/06/13(木)21:29 ID:/G8REiwP(1) AAS
RustはC/C++に置き換わるのか？
241(3): 2024/06/18(火)12:23 ID:/B9kzKJY(1) AAS
Rustの仕様と実装の分離ができてないと、公式の実装が唯一になるから困る分野があるんだろうね。
Cとかコンパイラいっぱいあるじゃん。
Rustぐらい複雑で成長途上の言語で仕様を文書化して実装を交換可能にするなんて事実上無理っぽいけど、10年後ぐらいには問題でてくるのかもね。
280(3): 2024/06/20(木)17:45 ID:sFnTxIc/(1/2) AAS
Rustのマクロは全言語の中でも優秀だからね
手続きマクロの強力さと利便性は他では代えがたい
宣言マクロももちろん衛生的(健全)で汚染がない
289(4): 2024/06/20(木)22:08 ID:0f6ktMCR(1) AAS
paiza.ioでクレートを追加する方法を教えてください
画像ﾘﾝｸ[png]:i.imgur.com
328(4): 2024/06/24(月)07:45 ID:m0RxboDo(1) AAS
if や case や match や テーブル参照は使わないで
(出来れば四則演算のみがベストアンサー)
変換前→変換後
1→2
2→1
3→3
4→10
6→4
8→8
10→6
省2
399(4): 2024/06/27(木)11:20 ID:veLj9zg3(1/4) AAS
よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど
441(3): 2024/06/28(金)09:41 ID:RD8xbJnt(1) AAS
型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ
469(5): 2024/06/29(土)15:34 ID:KH8yb7Br(1/6) AAS
それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある
さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある
しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる
Rust特有のリファクタリングしづらさは、あるよ
474(3): 2024/06/29(土)16:52 ID:KH8yb7Br(2/6) AAS
>>471
「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる
* 追加するライフタイムは既存のライフタイムと同じであるべきか
* 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?）
それで1つの型がリファクタリングできたところで、
* トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し
ここまでのすべての作業に尋常でない集中力が必要になる
繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ
「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、
作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る
省5
497(3): 2024/06/30(日)10:53 ID:DQMdIUg4(1) AAS
あえて >>493 で頑張ると
外部ﾘﾝｸ:paiza.io
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()
省3
534(3): 2024/07/01(月)12:59 ID:irzLgX5l(1) AAS
>>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)の部分は式やブロックの可能性もあるので簡略化せずに進めるね
省12
607(3): 2024/07/07(日)09:17 ID:7aG8TPof(1/2) AAS
>>604-605
ありがとうございました。
「継承」って良いからオブジェクト指向言語の機能になっていたのではないんですか？
なんか時代とともに、昔は良いとされていたものが今ではダメになったりするんですか？
なぜそんなに揺らぐのでしょうか？
言語の設計の学者はぼんくらばかりなんですか？
638(4): 2024/07/07(日)23:03 ID:Eha1J0DV(3/3) AAS
>>633
整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない
それと文字列 + 文字列が定義されている言語では
分数 + 整数の定義に必要な関数も継承したくない
その関数は文字列と無関係だから
657(3): 2024/07/08(月)11:27 ID:Qb4+6aEo(1) AAS
「実装は継承しているけど実装継承ではない」ｗ
660(3): 2024/07/08(月)13:25 ID:QAb8fFud(2/2) AAS
継承の本当の問題は、LSPを満たさない部分型関係を作ってしまいがちということ
他の型の実装に依存するのが良くないというのはDIの話で、直接は関係ない
684(3): 2024/07/09(火)21:07 ID:YflJELWV(5/6) AAS
>>683
あるトレイトでpanic2を禁止しようとしました。事前条件(あるいは例外条件)でnopanicとしたかったけど、そんなのは無いのでとりあえずデフォルト実装でpanic禁止にしました。
しかしトレイトユーザーはそんなのお構い無しにunsafe rustでpanicを使います。ついにpanicが発生してシステムダウンしました。
LSPでケアしている問題はRustのTraitを使っている限り発生しないんじゃないんだっけ？
685(4): 2024/07/09(火)21:56 ID:sTXYSGuF(2/2) AAS
Rustのトレイトは優れているため
LSPに違反するコード例を作ることができないんだよ
もしRustに文句をつけたかったら
LSPに違反する二つの型のコード例を作って示してごらん
Rustで違反例を作るのは不可能だよ
691(7): 2024/07/09(火)22:57 ID:/lHavWP5(1) AAS
>>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() }
}
省13
721(3): 2024/07/10(水)13:29 ID:kPG9kWdt(1/2) AAS
>>701
そのやり方がなぜ悪いのか理解できませんので、教えてください。
例えば、C++だと、以下の様にするのも別に悪いやり方ではないような
気がするのですが。
class Number {・・・};
Number add(Number &a, Number &b);
Number mul(Number &a, Number &b);
class Integer : public Number {・・・};
class Rational : public Number {・・・};
757(4): 2024/07/11(木)21:30 ID:wPVHCKh0(1) AAS
実際のところRustはサーバーサイドで使われてるの？
764(4): 2024/07/12(金)00:13 ID:0qGKBZrU(1) AAS
>>753 754
トレイトの場合はLSPで言うsupertypeやsubtypeになるのは
トレイトを利用して作られるimpl Traitやtrait objectの型だよ
PartialOrd/PartialEqやFn/FnMut/FnOnceのように
supertrait/subtraitの関係にあるやつも便宜的にトレイトで互換性が語られるけど
実際はそれらを利用して作られる型についての話なのと同じなんだよ
787(3): 2024/07/12(金)22:05 ID:LuKbokrL(5/9) AAS
>>785
参照カウンタ等がその別口
逆に聞くけど全てを参照カウンタで書かないのはなぜ？
812(3): 2024/07/13(土)10:59 ID:SqKWY/h6(1) AAS
>>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
831(3): 2024/07/13(土)15:38 ID:MYuplL5h(2/3) AAS
>>830
それLSPのどの項目に違反してる？
LSPは振る舞いに関する形式的なものなのでそのような意味論にまでは踏み込んでいないよ
897(3): 2024/07/19(金)23:30 ID:rC6z5NUh(2/2) AAS
>>886
let x; HashMap::<_, _> = vec.try_into()?;
>>889
＋１
903(3): 2024/07/21(日)09:43 ID:QhoywuRk(1/4) AAS
>>901
こういうのが「Rustは学習コストが高い」って言われる原因なんだろうな
答えを知ってる人は判ってても答えを知らない人は判らない
答えを調べるのにコストがかかりすぎる
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.085s