308(5): デフォルトの名無しさん [sage] 2015/12/20(日) 14:03:49.29 ID:ofrSOHxv(3/7) AAS
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話

311(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:36:58.02 ID:ofrSOHxv(4/7) AAS
>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例：　表示デバイスの数＞表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；

318(2): デフォルトの名無しさん [sage] 2015/12/20(日) 15:17:45.93 ID:14eB8c4R(1) AAS
>>315
もはやGCがどう関係するのかわからない

324(1): デフォルトの名無しさん [sage] 2015/12/20(日) 17:33:49.10 ID:6vo8OCaj(3/3) AAS
>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである