[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
5: デフォルトの名無しさん [sage] 2015/11/19(木) 02:10:36.00 ID:C+wDd3AI(1) AAS
>>33(1): デフォルトの名無しさん [sage] 2015/11/19(木) 00:14:59.30 ID:d0YkbYhs(1) AAS
仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし
126: デフォルトの名無しさん [sage] 2015/12/01(火) 00:23:09.00 ID:s1rcgCDh(1/3) AAS
Guilty Crown?
たしかに失敗作だったなあ…
229(1): デフォルトの名無しさん [sage] 2015/12/07(月) 15:38:30.00 ID:6rSJBSiX(1) AAS
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末
一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる
循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
240: デフォルトの名無しさん [sage] 2015/12/08(火) 00:48:22.00 ID:pyjW8EMu(1) AAS
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？
355: デフォルトの名無しさん [sage] 2015/12/21(月) 18:37:51.00 ID:ejqZ3DMD(24/26) AAS
Holiday Glam
外部ﾘﾝｸ:aurorawave.atspace.tv 画像ﾘﾝｸ
#AuroraWaveTV
666: デフォルトの名無しさん [] 2017/09/17(日) 15:38:01.00 ID:S40DCpdn(6/20) AAS
外部ﾘﾝｸ:ja.wikipedia.org動的メモリ確保
＞また、粒度の細かいページングは、ページングテーブル
＞(物理アドレスと論理アドレスの対応表)が大きくなるため、
＞4KB程度の大きなブロック単位でしか割り当てることができない。
ウィキペディア見るとそのアフォな実装がまかり通ってると読めるんだが・・・
719: デフォルトの名無しさん [sage] 2023/03/08(水) 00:10:24.00 ID:ZNO423TE(1) AAS
GCを含め、「機械に不慣れな人でも簡単にプログラミングできるようにする」という
これまで高級言語が行ってきたような試みはすべてAIに取って替わられるような気がする
まあ、現時点のAIは使い物にならないかもしれないが、いずれは…
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.054s