[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
207: デフォルトの名無しさん [sage] 2024/06/16(日) 13:26:09.91 ID:Crm/SwBu(1/7) AAS
あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。
395(2): デフォルトの名無しさん [sage] 2024/06/27(木) 10:21:46.91 ID:nawTLqWn(2/2) AAS
>>389389(1): デフォルトの名無しさん [sage] 2024/06/27(木) 04:33:33.49 ID:TDzAch9x(1/6) AAS
>>388
自分でヒープメモリ管理部分を書いてみるとよくわかる
ヒープでメモリ確保したり解放したりするのは色んな処理が入って非常に遅い
スタック上ならそのコストはない
関数に入る＆抜けるときにスタックフレームを指してるレジスタの値を変えるだけ
というのに加えて
CPUの多段メモリキャッシュ機構での速さが桁が変わってくる
スタックフレーム上なら常にアクセスしていてキャッシュに載るから超速い
キャッシュに乗るという前提なら、
確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？
キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな
399(4): デフォルトの名無しさん [sage] 2024/06/27(木) 11:20:07.91 ID:veLj9zg3(1/4) AAS
よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど
417(1): デフォルトの名無しさん [sage] 2024/06/27(木) 22:40:30.91 ID:TDzAch9x(5/6) AAS
>>406406(2): デフォルトの名無しさん [sage] 2024/06/27(木) 13:24:58.99 ID:veLj9zg3(2/4) AAS
スタックてのは関数が何段か終了して縮んだあと、また伸び直して前の伸びを上書きしちゃうでしょって話
とにかく「移動」というのが新しくて、代入の移動はわかったけど
関数呼び出しの引数も移動です、返り値も移動ですってのがどういう実装に落とされるのかまだわかってない
そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ
moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない
こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない
だからmoveはmoveとして理解することが唯一の正解でしょう
629: デフォルトの名無しさん [sage] 2024/07/07(日) 17:13:03.91 ID:KUDE2scl(1) AAS
継承はいらん。
理想(のひとつ)はダックタイプで、継承は実装上の都合でそうなっている妥協の産物でしかない。
679(2): デフォルトの名無しさん [sage] 2024/07/09(火) 15:20:15.91 ID:aoAam1/W(3/5) AAS
>>676676(1): デフォルトの名無しさん [sage] 2024/07/09(火) 13:35:41.29 ID:YflJELWV(3/6) AAS
>>675
＞明記されてるのが見えないのかね
＞Rustのtrait自体はオブジェクトを持たない
それは「RustのTraitはLSPと関係ない」と言いたいの？
＞φが存在しないため事前条件も何もない
事前条件も何も表明できないのは「力不足」そのものですな。
LSPに明記されている前提すら満たさない異なるものであるため
「RustのTraitはLSPと関係ない」で合っている
LSPが対象としている遺物における諸問題に悩まされずに済むように
新たな視点で整理されたより良いものとしてRustのTraitが提供されている
801(1): デフォルトの名無しさん [sage] 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 1.552s*