[過去ﾛｸﾞ]
Rust part24 (1002ﾚｽ)
Rust part24 http://mevius.5ch.net/test/read.cgi/tech/1716759686/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
460: デフォルトの名無しさん [sage] 2024/06/29(土) 13:28:37.21 ID:7275QU0+ >>458 そういうRustでのリファクタリングならば大手術にならない メモリ保有を適切な位置に移したり分解したりするなどの単純なリファクタリングで済んでいる それにより保守性もデバッグ効率も上がるためリファクタリングコストは誤差に等しい 仮にGC言語で書いている時でも同様でその状態は各データが複雑に絡み合っている状態なのでリファクタリングしたほうが望ましい http://mevius.5ch.net/test/read.cgi/tech/1716759686/460
461: デフォルトの名無しさん [sage] 2024/06/29(土) 13:38:30.46 ID:xx5BdVU7 ダックタイピングがあるってどういう状態のことだろう http://mevius.5ch.net/test/read.cgi/tech/1716759686/461
462: デフォルトの名無しさん [sage] 2024/06/29(土) 14:06:46.53 ID:H9n2Ca7a リファクタリングの原則のひとつとして外側から見たときに変わらないというのがある。 内と外を分ける境界線がどこなのかというのは場合によるので UI レベルで同じなら良しとすることもあるけど、普通は適当なモジュール単位でやるだろう。 「変わらない」ことの保証のひとつとして型やライフタイムアノテーションは頼りになるよ。 型システムがあてにならないほどの大改革ならどうせ全部書き直しなので足を引っ張られることもない。 http://mevius.5ch.net/test/read.cgi/tech/1716759686/462
463: デフォルトの名無しさん [] 2024/06/29(土) 14:24:33.15 ID:lbQtaoAJ Rustはリファクタリングには全く向いていない http://mevius.5ch.net/test/read.cgi/tech/1716759686/463
464: デフォルトの名無しさん [sage] 2024/06/29(土) 14:31:05.74 ID:dyJ1RvLM いつも汚いコードを貼り付けてた複オジがリファクタリングは簡単などと言い張ったところで全く説得力がない http://mevius.5ch.net/test/read.cgi/tech/1716759686/464
465: デフォルトの名無しさん [sage] 2024/06/29(土) 14:38:55.22 ID:pz5Aaald 数のイテレータで遊んで満足してる人に機械学習の文脈が理解できるわけないやん？ http://mevius.5ch.net/test/read.cgi/tech/1716759686/465
466: デフォルトの名無しさん [sage] 2024/06/29(土) 14:41:30.81 ID:Kxp5xIIU 掲示板に貼れる程度の内容なら リファクタリングしても知れてるでしょ http://mevius.5ch.net/test/read.cgi/tech/1716759686/466
467: デフォルトの名無しさん [sage] 2024/06/29(土) 15:08:40.24 ID:BT1eNZRh >>463 Rustはリファクタリングに向いている言語だよ リファクタリングで最も重要なことはその前後で同じ機能動作が保証されることだけど そこで静的型付け言語が有利なことは当たり前としてRustのアクセス競合排他原則がさらに大きく効いてるよ データ書き換え中の読み取りによるバクがリファクタリングによって入り込むことも防いでくれているね http://mevius.5ch.net/test/read.cgi/tech/1716759686/467
468: デフォルトの名無しさん [sage] 2024/06/29(土) 15:23:13.20 ID:PsPEDCdZ デジタル小作人やめるレベルの大手術ではなく 地主との関係が変わらないことを保証したいんだな http://mevius.5ch.net/test/read.cgi/tech/1716759686/468
469: デフォルトの名無しさん [sage] 2024/06/29(土) 15:34:20.66 ID:KH8yb7Br それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる Rust特有のリファクタリングしづらさは、あるよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/469
470: デフォルトの名無しさん [sage] 2024/06/29(土) 15:52:41.67 ID:jlQztVvs ライフタイム関連に限らずRustのリファクタリングは 他言語に比べて波及する範囲が大きくなりやすいんだよね それで作業量が多いからしんどい しんどさと難しさは必ずしもイコールではないんだけど サクサク変更できる言語を経験してると Rustのリファクタリング時には精神的なエネルギーが相当必要 http://mevius.5ch.net/test/read.cgi/tech/1716759686/470
471: デフォルトの名無しさん [sage] 2024/06/29(土) 16:01:57.62 ID:obFhbebh >>469 リファクタリングの作業の大きさに対して、必要なライフタイム注釈を付けるだけの些細なことが障害になったことはないな。 ライフタイム注釈が'aになるか'_になるか省略できるかは、その必要性と省略ルールに基づくだけなので、そこで問題が発生することはないだろう。 http://mevius.5ch.net/test/read.cgi/tech/1716759686/471
472: デフォルトの名無しさん [sage] 2024/06/29(土) 16:03:28.89 ID:obFhbebh >>470 Rustでは様々なことをコンパイラチェックに任せられるため、リファクタリングで最も崩れにくく、人間の負担は他より小さい。 http://mevius.5ch.net/test/read.cgi/tech/1716759686/472
473: デフォルトの名無しさん [sage] 2024/06/29(土) 16:10:10.85 ID:FxtNCeeF 糠に釘 暖簾に腕押し 複オジにRust http://mevius.5ch.net/test/read.cgi/tech/1716759686/473
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
475: デフォルトの名無しさん [sage] 2024/06/29(土) 16:58:20.78 ID:KH8yb7Br Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない http://mevius.5ch.net/test/read.cgi/tech/1716759686/475
476: デフォルトの名無しさん [] 2024/06/29(土) 16:59:51.95 ID:TiydCxUm 知ったかぶりして間違ったこと書く やんわり間違いを指摘される 反省せずに開き直る！ またこの流れ ググればすぐわかるような間違いなのになんなんだろうな http://mevius.5ch.net/test/read.cgi/tech/1716759686/476
477: デフォルトの名無しさん [sage] 2024/06/29(土) 17:06:14.07 ID:HTwQ17U9 >>474 >>475 それは大きな誤解をしているなあ ライフタイムアノテーションを間違って書いて矛盾が起きていればコンパイルエラーとなるよ コンパイルが通れば正しく書けているからプログラマーがそこで困ることはないよ http://mevius.5ch.net/test/read.cgi/tech/1716759686/477
478: デフォルトの名無しさん [sage] 2024/06/29(土) 17:17:23.37 ID:KH8yb7Br >>477 いいからこれでも読んでろ https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md > Rustのトレイトオブジェクトへのライフタイム省略ルールはどんな状況でも正しいというわけではない > Rustはプログラムの意味についてプログラマよりも知っているわけではない > Rustのコンパイラが吐くエラーメッセージでおすすめされる修正はコンパイルが通るようにするが、コンパイルが通り、 かつ プログラムへの要求をちゃんと満たしたものするわけではない http://mevius.5ch.net/test/read.cgi/tech/1716759686/478
479: デフォルトの名無しさん [sage] 2024/06/29(土) 17:26:08.00 ID:3fxfEuZj それは省略ルールの結果が望むものと一致するかどうかは限らないという意味だぜ 間違っていると部分的にはコンパイルが通ったとしてもプログラム全体ではコンパイルエラーとなる そのミスをコンパイラが見逃すことはない http://mevius.5ch.net/test/read.cgi/tech/1716759686/479
480: デフォルトの名無しさん [sage] 2024/06/29(土) 18:07:09.50 ID:PsPEDCdZ 言語を比較しなくても &Tに比べてRc<T>はリファクタリングしやすいとかいう認識でいいよな ただ進化論じゃないんだから&Tが淘汰されてRc<T>が生き残るということはない 言語を比較すれば淘汰される言語もありうる http://mevius.5ch.net/test/read.cgi/tech/1716759686/480
481: デフォルトの名無しさん [sage] 2024/06/29(土) 18:13:00.59 ID:E9RFAyQx >>469 その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね http://mevius.5ch.net/test/read.cgi/tech/1716759686/481
482: デフォルトの名無しさん [] 2024/06/29(土) 18:24:11.81 ID:bsok8bJg C/C++をメモリ安全にするプロジェクト https://www.itmedia.co.jp/enterprise/articles/2406/28/news084.html Rustイラネになりそう http://mevius.5ch.net/test/read.cgi/tech/1716759686/482
483: デフォルトの名無しさん [sage] 2024/06/29(土) 18:44:47.93 ID:4ikwzvl0 >>482 それは自動で見つけられる脆弱性の範囲を広げる話 その種の脆弱性をゼロにするRustへと移行する流れはそのまま変わらず http://mevius.5ch.net/test/read.cgi/tech/1716759686/483
484: デフォルトの名無しさん [sage] 2024/06/29(土) 20:21:20.41 ID:U1RWDnMp >>480 Rc<T>の比較対象はTやBox<T> ・Tの参照は&T ・Box<T>の参照は&T ・Rc<T>の参照は&T どれも同じになり&Tは不要とならない 違いはスコープから外れたとき 裸のTはTがスタック上ですぐ消える Box<T>はTがヒープ上ですぐ消える Rc<T>はTがヒープ上でカウンタが最後のときだけ消える http://mevius.5ch.net/test/read.cgi/tech/1716759686/484
485: デフォルトの名無しさん [sage] 2024/06/29(土) 20:23:11.41 ID:KH8yb7Br >>469 これか…… https://github.com/rust-lang/cargo/issues/7342 > I think the answer here is "Alex thought it was fun to avoid RefCell and Mutex", there's no real technical motivation. 「cloneを避ける/ロックを避ける/参照カウンタのコストを避ける」みたいなゼロコスト主義も節度を持ってやれってことね とりあえず「型のジェネリックライフタイム引数を変更するのは多大なコストがかかる」という理解は合っていると思っておくことにするか http://mevius.5ch.net/test/read.cgi/tech/1716759686/485
486: デフォルトの名無しさん [sage] 2024/06/29(土) 20:23:40.20 ID:KH8yb7Br >>481だった http://mevius.5ch.net/test/read.cgi/tech/1716759686/486
487: デフォルトの名無しさん [sage] 2024/06/29(土) 21:57:07.55 ID:PsPEDCdZ 問題は節度というより抽象化軽視 ゼロコストという損得勘定に強く依存するよりは高コスト抽象化の方がマシ と判断できなくなる http://mevius.5ch.net/test/read.cgi/tech/1716759686/487
488: デフォルトの名無しさん [sage] 2024/06/29(土) 22:55:28.22 ID:xDrSJDK+ >>469 それは単にライフタイムに不慣れなだけじゃないかなと思った 構造体に参照を含むのはよくあることでライフタイムパラメタを付けるだけ あとは関数で参照を含むデータを返す時にどの引数に由来するかを指定することなどしかすべきことはない 慣れてしまうと大したことはしていないよね そこでもし間違えて指定してしまっても違反があればコンパイラが必ずエラーとするので安心して大丈夫 では何故コンパイラが自動で指定(解釈)してくれないのか？というと、複数の参照に対して別扱いするかどうかや複数の関係指定など各自に方針の余地があるため http://mevius.5ch.net/test/read.cgi/tech/1716759686/488
489: デフォルトの名無しさん [] 2024/06/29(土) 23:12:35.54 ID:/LX7F2Md C/C++だとそのへんを脳内の方針で逸脱しないように人間が監視しないといけない Rustは楽 http://mevius.5ch.net/test/read.cgi/tech/1716759686/489
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 513 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.019s