[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
306(3): デフォルトの名無しさん [sage] 2015/12/20(日) 13:48:14.94 ID:HXRBhwTH(2/3) AAS
>>304304(2): デフォルトの名無しさん [sage] 2015/12/20(日) 12:13:23.36 ID:ofrSOHxv(1/7) AAS
>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
Cオープン
A生成
B生成
A, B使用
B開放
A開放
Cクローズ
でええやん？
さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
308(5): デフォルトの名無しさん [sage] 2015/12/20(日) 14:03:49.29 ID:ofrSOHxv(3/7) AAS
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？
つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
320: デフォルトの名無しさん [sage] 2015/12/20(日) 17:05:42.48 ID:6vo8OCaj(1/3) AAS
>>319>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない
読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない （>306）
と言い切ることはできないとかそういう話
で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
>>318ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
321: デフォルトの名無しさん [sage] 2015/12/20(日) 17:12:24.84 ID:6vo8OCaj(2/3) AAS
ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s