[過去ログ]
GCは失敗。メモリは自分で管理せよ! その2©2ch.net (720レス)
GCは失敗。メモリは自分で管理せよ! その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
363: デフォルトの名無しさん [sage] 2016/01/27(水) 17:10:09.80 ID:eULyfEEH GCのすべてを否定するつもりはないけど・・・ GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・ むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況 だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について 自動で芋づる式に呼び出してくれない だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない 当たり前にDisposeの呼び出し忘れが有ってもいけない まるで、mallocしたらfreeするのと似ている しかもIDisposableはコンポジションで増殖する IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合 C#のようにコンパイラマジックでなんでも実現する言語で どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ http://mevius.5ch.net/test/read.cgi/tech/1447856699/363
364: デフォルトの名無しさん [sage] 2016/01/27(水) 17:24:38.54 ID:eULyfEEH 謎だといったが、理由ははっきりしていて メンバのDisposableを自動で呼び出す為には 他で使われてないことを保証する必要があって 参照カウンタ方式のようにローコストなものなら簡単に分かるが これでは循環参照の問題が出る プログラマが循環参照を気にしなくてもよいことが前提の マークスイープ系のGCを搭載した言語では設計思想が破たんするので 参照カウンタ方式は採用できないし マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので 自動でDisposeを呼び出す仕組みを用意できない どうにもならない 結局C++の方式が一番優れている 循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば GCにまつわる他の問題が一切発生しない http://mevius.5ch.net/test/read.cgi/tech/1447856699/364
365: デフォルトの名無しさん [sage] 2016/01/27(水) 17:46:52.79 ID:eULyfEEH もっと言えばC#でDisposeを実装する場合でも↑は問題になる 自身のメンバのDisposeを呼んでよいのかどうなのか 完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない GC任せにするか、自分で参照カウンタを実装するか どちらにせよ、RAIIと相性が悪い http://mevius.5ch.net/test/read.cgi/tech/1447856699/365
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.035s