[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
423(1): デフォルトの名無しさん [sage] 2016/03/27(日) 07:41:27.84 ID:kBj57j3O(2/3) AAS
>>420420(1): デフォルトの名無しさん [sage] 2016/03/27(日) 01:31:49.74 ID:vj+h39OC(3/10) AAS
>ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。
それはGC関係ないRAIIの話だろ
C#でもusing使えばRAII出来るが
usingも、ローカル変数も、deleteも、何れもGCじゃない
手動で寿命管理しているに過ぎない
寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ
>それはGC関係ないRAIIの話だろ
メモリはGCで回収されると書いたが？あと、そもそもRAII自体がGCと直接関係ないとも書いた。
>usingも、ローカル変数も、deleteも、何れもGCじゃない
いずれもメモリ領域はGCで回収される。
>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ
ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。
「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。
428(1): デフォルトの名無しさん [sage] 2016/03/27(日) 16:21:42.54 ID:vj+h39OC(6/10) AAS
>>423
そんな基本的なことを言って何がしたいの？
RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; }; といった感じのクラスになる、分かるよね？
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね？
このとき、マークスイープ系GCだと、my_classのobｊに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない
もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう
参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い
>>424424(2): デフォルトの名無しさん [sage] 2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y(3/6) AAS
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
お前言ってること無茶苦茶すぎるだろ
>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない
GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s