[過去ﾛｸﾞ]
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
597: デフォルトの名無しさん [sage] 2016/11/15(火) 00:00:47.13 ID:PldPJ2O3 マークスイープ系GCはメモリ管理に関しては完璧かもしれないが それ以外のリソースの面倒は一切見てくれない そういったものはファイナライザで開放すればよいわけだが 要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある もしかしたら他の誰かが使用中かもしれない、という場面もありうる だから誰も使ってないことをプログラマが保証する格好になる その意味ではfree()と大差ないわけで usingという構文が用意されていて、ある程度自動で呼ばれるというだけである 本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので 都度都度チェックできるし、要らなくなったらその場で即開放できるので Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし スマポを使えばデストラクタ自体、書く必要すらないかもしれない そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても 芋づる式に自動で呼ばれる これはDisposeには無い機能だ 何故無いのか？答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ 誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ http://mevius.5ch.net/test/read.cgi/tech/1447856699/597
598: デフォルトの名無しさん [sage] 2016/11/15(火) 00:02:48.22 ID:PldPJ2O3 本当にC#で解放処理をまともに書こうと思うと 自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ もし、実装しているものがあれば、自身もIDisposableにし Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない これを手作業でやる C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が 非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる mallocしたらfreeしましょうと同レベルのことを強いられる このように面倒なIDisposableであるが IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる このように、まじめに考えると、破たんした方法であることが分かる 根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが 確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという ある種手作業なusingがせいぜいである 参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので これらの問題は一切発生しない 解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので 手動でコードを書かなければならないということもない ランタイムもシンプルであり、バグった時も再現性が期待できる http://mevius.5ch.net/test/read.cgi/tech/1447856699/598
599: デフォルトの名無しさん [sage] 2016/11/15(火) 00:24:03.03 ID:PldPJ2O3 これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに マークスイープ系GCにまつわる数々の問題点を排除したのだ マークスイープ系GCで有利なのは唯一循環参照だけであり そこさえ気を付けることができれば それ以外の部分に関しては参照カウンタのほうが優れている C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ 今になって考えるとその選択は正しかったと思う http://mevius.5ch.net/test/read.cgi/tech/1447856699/599
607: デフォルトの名無しさん [sage] 2016/11/15(火) 10:53:43.30 ID:PldPJ2O3 struct test { std::shared_ptr<int> ptr; test(){ ptr = new int; } }; 上のコードはデストラクタを書く必要があるのかないのか スマポを使えばデストラクタを書かなくてよい場合もあり得るということ スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう なので、「スマポ」と「デストラクタを書く必要性」は、関係がある ちなみにC#のDisposeはただのメソッドであるので このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし マークスイープなので原理上不可能である 他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので 自動化できない http://mevius.5ch.net/test/read.cgi/tech/1447856699/607
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.034s