Go language part 6 (70ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
37(1): 06/15(日)01:14 ID:757F+le4(1/5) AAS
>>35
> 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
それがarenaで簡単になるらしいぞ、詳しくは知らんが
> これがAがResponseを参照している、BがResponseを参照しているの意味なら
そうだが、
> AやBより先に他の誰かがResponseを生成して所有しているはずで
これはその下のCの話になってる
問題が起きるケースは、
A->Response のオブジェクトAがあり、
オブジェクトBにもResponseの参照が欲しくなったので、B->Responseをつけようとするが、
省14
38: 06/15(日)01:41 ID:757F+le4(2/5) AAS
>>37、例を修正、
(まあ俺がRustに詳しいわけではないからコンセプトだけだが、)
function add_ref(Response, A, B){ // Response,A,Bはすべて所有権を与えられるとする
A.Response = Response; // この辺が書けない
B.Response = Response; // この辺が書けない
return [A,B]; // 2値返し、A,Bのどちらが長寿命かはわからない
}
かな。Responseが与えられ、A,Bにそれぞれ参照を付加するだけだが、
Responseオブジェクトの寿命(所有権？)をどちらに与えればよいか分からない
だからまるごと管理してしまえってのがCなりarenaなのだろうし、
省2
49(1): 06/15(日)06:46 ID:757F+le4(3/5) AAS
>>41
> 手動で解放があることを前提とした前処理
とは何ぞ？
仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い
多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、
それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と
アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる
50(1): 06/15(日)08:34 ID:757F+le4(4/5) AAS
>>41
ところでGoは生ポなのでコンパクションは出来ないだろ
コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる
だから、GCと一括りはまずくて、
コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち
と別扱いにしないといけないと思うが
省3
53: 06/15(日)11:42 ID:757F+le4(5/5) AAS
>>52
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.016s