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