[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)

GCは失敗。メモリは自分で管理せよ！ その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

429: デフォルトの名無しさん [sage] 2016/03/27(日) 16:43:31.54 ID:vj+h39OC C++で書けば struct A{ *obj }; void func() { 　　A a; } こういったRAIIの場合のobjの開放はどういう扱いにするんだって話 aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい しかし、objが彼方此方から参照されている可能性もあるので そこんとこコンパイラは判断が付かないので、自動化はきない あくまで、プログラマが保証する形になる C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる しかも、所有権が単一である場合にしか成り立たない 一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう 参照カウンタはこれらの問題をすべて解決する 参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので スマポを使っておけば呼び出し忘れるということもないし Disposeのような冗長なコードを書く必要もない http://mevius.5ch.net/test/read.cgi/tech/1447856699/429

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

あと 291 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.018s