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