Rust part24

138(2): デフォルトの名無しさん [] 2024/06/14(金) 23:46:55.69 ID:49Oug44p(2/2) AAS
ゲームはまずdirectxやopenglとかがrustで書き直されないことには何も始まらんと思うわ

205(1): デフォルトの名無しさん [sage] 2024/06/16(日) 12:42:20.38 ID:dwkxcYMW(16/22) AAS
代入だったり関数呼び出しの引数だったりはコピーじゃなくて移動がキホンって時点で機械語ともC言語とも違う

372(2): デフォルトの名無しさん [sage] 2024/06/25(火) 23:30:51.26 ID:oKw2Pfcc(1) AAS
>>347
展開しないほうがよい

展開する時も二重ループは発生するだけでなく単なる計算より重い
さらに本来は回避できる浮動小数点を使わざるを得なくなる
そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない

一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる
割り算部分も0/N=0かN/N=1だけなので整数で済む

474(3): デフォルトの名無しさん [sage] 2024/06/29(土) 16:52:22.95 ID:KH8yb7Br(2/6) AAS
>>471
「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる

* 追加するライフタイムは既存のライフタイムと同じであるべきか
* 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?）

それで1つの型がリファクタリングできたところで、

* トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し

ここまでのすべての作業に尋常でない集中力が必要になる
繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ
「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、
作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る
「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない
少なくとも自分の頭では作業の段取りを崩すだけだった

そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない
ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ

こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい

475(1): デフォルトの名無しさん [sage] 2024/06/29(土) 16:58:20.78 ID:KH8yb7Br(3/6) AAS
Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる
しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない

309(1): デフォルトの名無しさん [sage] 2024/06/22(土) 23:41:03.46 ID:jxx0duBQ(1) AAS
関数型というとfor文使うのではなくこんなイメージ

fn main() {
　std::env::args().skip(1).for_each(|file_name| {
　　println!("{}", file_name);
　　std::fs::read_to_string(&file_name).map(|lines| {
　　　lines.lines().enumerate().for_each(|(i, line)| {
　　　　println!("{:>2}:{}", i + 1, line);
　　　})
　　})
　})
}