[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
207: 2024/06/16(日)13:26:09.91 ID:Crm/SwBu(1/7) AAS
あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。
395(2): 2024/06/27(木)10:21:46.91 ID:nawTLqWn(2/2) AAS
>>389
キャッシュに乗るという前提なら、
確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？
キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな
399(4): 2024/06/27(木)11:20:07.91 ID:veLj9zg3(1/4) AAS
よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど
417(1): 2024/06/27(木)22:40:30.91 ID:TDzAch9x(5/6) AAS
>>406
そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ
moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない
こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない
だからmoveはmoveとして理解することが唯一の正解でしょう
629: 2024/07/07(日)17:13:03.91 ID:KUDE2scl(1) AAS
継承はいらん。
理想(のひとつ)はダックタイプで、継承は実装上の都合でそうなっている妥協の産物でしかない。
679(2): 2024/07/09(火)15:20:15.91 ID:aoAam1/W(3/5) AAS
>>676
LSPに明記されている前提すら満たさない異なるものであるため
「RustのTraitはLSPと関係ない」で合っている
LSPが対象としている遺物における諸問題に悩まされずに済むように
新たな視点で整理されたより良いものとしてRustのTraitが提供されている
801(1): 2024/07/13(土)08:51:48.91 ID:zzh5ASvo(2/5) AAS
>>784
いくつものバージョンのrustやそのバージョン用のcratesを
それぞれ独立に管理して切り替えて使える統合環境なら嬉しいな
venvみたいな
818(1): 2024/07/13(土)11:54:54.91 ID:mV5TIlCk(3/8) AAS
それはコンパイルのされ方の話であって意味の上での問題ではない気がする
Box<dyn T> なら動的ディスパッチされるわけだし
let x: T = ... のような変数を作れないという意味ならその通りだけど、それはオブジェクト指向言語におけるインターフェースでも同じでは
(それともインターフェースに対してLSPは成り立たない？)
991: 2024/07/30(火)22:49:06.91 ID:MqLM+D1V(1/3) AAS
最適化じゃなくて単に移動の問題
Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する
その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える
だとすると最適化の有無は関係なく起こる気がする
ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない
これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.052s