トップページ⇒tech
75コメント25KB

C/C++でガベージコレクション

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/08/28(日) 09:30:25
C/C++でもガベージコレクションをやりたいですよね。
VisualC++の__gcや、BoehmGCなどについて語りましょう。
0002デフォルトの名無しさん2005/08/28(日) 10:11:44
そんな小手先の技使うより、言語使用にgcっていう記憶クラス増やしたほうがいい。
0003デフォルトの名無しさん2005/08/28(日) 10:53:36
コンサバは信用ならん。
0004デフォルトの名無しさん2005/08/28(日) 10:59:52
mallocすら信用できん業界で生きています。
0005デフォルトの名無しさん2005/08/28(日) 13:59:27
C++で問題なくガーベッジコレクタが動けばデストラクタ不要！
0006デフォルトの名無しさん2005/08/28(日) 14:05:36
Javaの
java.lang.ref.Referenceみたいなインターフェスは
C++にはあるのか？
こいつを使って
WeakReference e = new WeakReference(到達可能性を変更したいオブジェクト);

みたいなことはできないのか？
到達可能性を変更することでガーベッジコレクタによって
オブジェクトが破棄されるタイミングを変えることで
パフォーマンスを変えてしまうのだ。

これをC++で容易に実現したい。

なお、Javaの到達可能性は5段階存在する。

デフォルトの到達可能性。
# 強可到達オブジェクトとは、参照オブジェクトをトラバースすることなく、あるスレッドによって到達できるオブジェクト。新しく作成されたオブジェクトは、それを作成したスレッドによる強可到達

SoftReference
# ソフト可到達オブジェクトとは、強可到達ではないが、ソフト参照をトラバースすることで到達できるオブジェクト
WealReference
# 弱可到達オブジェクトとは、強可到達でもソフト可到達でもないが、弱参照をトラバースすることで到達できるオブジェクト。弱可到達オブジェクトへの弱参照がクリアされると、そのオブジェクトはファイナライズの対象となる
PhantomReference
# ファントム可到達オブジェクトとは、強可到達でも、ソフト可到達でも、弱可到達でもなく、ファイナライズされており、ファントム参照がそれを指しているオブジェクト

到達不可能すなわちガーベッジコレクタによってオブジェクトが破棄されない
# 最後に、オブジェクトがどのようにも到達できない場合、そのオブジェクトは不可到達であり、そのため再生の対象となる
0007デフォルトの名無しさん2005/08/28(日) 14:28:37
ソフト参照って機能面で強参照と変わらなく無いですか？
0008デフォルトの名無しさん2005/08/28(日) 14:50:07
>>5
デストラクタはファイルやロックの解放にも使われるんで、そうはいかんｚ
0009デフォルトの名無しさん2005/08/28(日) 17:03:11
javaプログラマはtryしてcloseするのが
まさにdeleteだと気づけ
javaにガベージコレクタなんかねーから
0010デフォルトの名無しさん2005/08/28(日) 23:11:46
>>9
意味の無い妄想を書き込む前に、
トレース型ＧＣを用いる場合、リソースの開放は自前で行うことが望ましい。
という問題の本質に早く気づけ。
0011デフォルトの名無しさん2005/08/28(日) 23:23:32
「湯水のように使うことのできないリソース」というべきでは。
メモリだってリソースだし。
0012デフォルトの名無しさん2005/08/28(日) 23:32:31
痛いとこ突かれたjava厨が
意味無いということにして逃げまくってますね ;-)
0013デフォルトの名無しさん2005/08/28(日) 23:34:02
「ガベージコレクション」の意味がわかってないアホがいるようですね
0014デフォルトの名無しさん2005/08/29(月) 00:56:07
>>12
必死だな（ｗ
と言うのを初めて書き込む事になった件について。
0015デフォルトの名無しさん2005/08/29(月) 01:06:34
たったこれだけのスレなのになんで
喧嘩になってのかわかんねー俺がいる（核爆
0016デフォルトの名無しさん2005/08/29(月) 01:09:36
進化しつづけるC++と完成してるJavaをお互いにねたみあってるわけですな
0017デフォルトの名無しさん2005/08/29(月) 01:35:57
デジタルマーズC++ならGCライブラリが付いてくるでしょ？

Javaもfinalizeをデストラクタに使えるけど
処理タイミングに同期がどれないのは痛すぎる。

クリティカルみたいな識別子を指定できたらなぁ
0018デフォルトの名無しさん2005/08/29(月) 02:41:58
>>8
Javaみたいに
Stream#close()
とか
Thread#notify()
とかできるようにすればいいのに。
それでデストラクタ不要にもってけるように
設計できんかいな？
0019デフォルトの名無しさん2005/08/29(月) 02:48:08
>>9
Javaにガーベッジコレクタが無い？
何いうとるのか。よくわからない。説明求む。

>>9-以降に聞きたい、>>6は見ているのか？

>>15と同じようになんで喧嘩になっているのかよくわからぬ。
>>12もよくわからないことを言ってるし。狂ってるとちゃうか？

>>16
よくわからないな。それならC#とJavaとの関係のほうが「ねたみあう」「睨み合う」にふさわしい言葉じゃないかな？
Javaにあれだけすばらしい機能があるのに、C++にはそういう機能は無いのか？と>>6で質問したのだが。
0020デフォルトの名無しさん2005/08/29(月) 03:52:00
>>19
ないなら作ればいいやん。
C++のGCの実装は言語の機能じゃなくてライブラリでしょ。
0021デフォルトの名無しさん2005/08/29(月) 03:52:51
誰か親切人教えて～キーボードが普通に入力できなくなって
しまったんだけど、どこおせば直る？ローマ字からひらがなにならねぇ～


0022デフォルトの名無しさん2005/08/29(月) 07:29:21
スペースの右にある

カタカナ
ひらがな


押せば直る
0023デフォルトの名無しさん2005/08/29(月) 10:21:25
俺は6でも9でもないが。
>>19
JavaにGCがないというのはこれを揶揄的に言っているだけだろう。
> javaプログラマはtryしてcloseするのが
> まさにdeleteだと気づけ

Javaは全く知らないので、WeakReferenceをググってみたが、
boost::weak_ptrが近いのではないかと思う。boost::shared_ptr(参照カウント)用。
0024デフォルトの名無しさん2005/08/29(月) 11:05:35
>>17
>クリティカルみたいな識別子を指定できたらなぁ

その識別子を指定してあるオブジェクトが破棄されている　かもしれない　ってだけで、
何回無駄なGC動かせばいいんだ？
あるスコープから外れるたびに、GC動かさなきゃいけなくなるが
0025デフォルトの名無しさん2005/08/29(月) 21:30:32
ヒープ外に作ればいいんじゃねーの？
nioなんかで既にやられてることじゃん
0026デフォルトの名無しさん2005/08/30(火) 18:17:05
gccにVC++の__gcみたいなガベージコレクタってありませんか？
0027デフォルトの名無しさん2005/08/30(火) 19:44:47
gccならなおさらBoehmGC使えよ
相性抜群
0028デフォルトの名無しさん2005/08/30(火) 21:06:50
循環参照に対応できてないやつはウンコ
0029デフォルトの名無しさん2005/08/31(水) 03:17:47
ウンコ は 循環参照に対応できてない。。。正しい。
0030デフォルトの名無しさん2005/08/31(水) 10:39:33
>>29
逆命題の真偽は元の命題の真偽と関係ないよ
0031デフォルトの名無しさん2005/08/31(水) 15:47:10
「数学なんて社会に出ても役に立たない」とか言う奴は、
大抵命題の無理解でコミュニケーションに重大な支障をきたす。
まともなら2秒で通るものが、そのせいで数日こじれたりする。
0032デフォルトの名無しさん2005/09/01(木) 00:04:53
あえて根拠は書かない作戦ですか？
0033デフォルトの名無しさん2005/09/01(木) 01:04:30
意味がわかりません。
0034デフォルトの名無しさん2005/09/02(金) 00:34:52
>>31
大いに同意
実例求む
0035デフォルトの名無しさん2005/09/02(金) 04:04:24
C++/CLIやBoostを使えばそれほど意識せずに済むんじゃね？
0036デフォルトの名無しさん2005/09/02(金) 18:38:03
boostじゃ無理
0037デフォルトの名無しさん2005/09/02(金) 20:29:43
なんだ数学の話か？
プログラマ誰にとっても必要なのってド・モルガンぐらいじゃね？

俺業務系だから、高校数学レベルでさえつかわんよ。線形代数とか三角関数とか
微積分とか。
0038デフォルトの名無しさん2005/09/02(金) 20:50:22
>>31
なんとなくわかる。それで思考をあっさりあきらめてもらう奴の方がよっぽどいい。

>>37
何も数字や数字をあらわす文字を扱うものだけが数学じゃない。
数字や計算とはまったく関係ない数学こそがここではもっとも求められる。
システム論だって数学だし、
マルチスレッドのデッドロック回避問題だって数学だ。


話は変わるけど、ガベジコレクションはやっぱりいらんと思うぞ。
適切な後始末処理を適切なクラスが各々責任をもって実装する、という習慣がつけば
そもそもメモリリークに悩まされることなんてないし。できあがったシステムは自然に
カプセル化などが施されてまとまったものになる。
デストラクタがアンリライアブルになったことによるマイナスのほうがはるかに大きいと俺は思うんだが。

0039デフォルトの名無しさん2005/09/02(金) 21:01:27
>>38
後始末処理をデストラクタに書くってのが、そもそも悪習慣であるというのが
GC大好き派の意見です。
0040デフォルトの名無しさん2005/09/02(金) 21:45:08
んー、やっぱ機械でできることは機械にやらせたいな。
「適切」に資源を管理するのに費やされる「脳力」を「適切」なロジックの決定などに費やせるし。
0041デフォルトの名無しさん2005/09/02(金) 22:15:29
>>38
そりゃGC環境内では後始末をいつ実行されるかわからんデストラクタに任すのは間違いなく悪習慣なのだが、
そういうことじゃなくて？

>>40
いやいや、適切に資源を管理することと、適切なロジックを構築することは方向性が
一緒なんですよ。資源を自分で管理することによってロジック構築の訓練にもなる、といいのだよ。

しかし、俺の部屋のケイオス状態を見たら、資源の管理なんて主張できた義理じゃないな。
掃除するか。
0042デフォルトの名無しさん2005/09/02(金) 22:18:09
ただ、俺の場合、デストラクタのないクラスが出来上がることもあるよ。
もちろん、メンバはstd::fstream系やスマートポインタ、コンテナのように間違いなくデストラクタを持っている。
0043デフォルトの名無しさん2005/09/02(金) 22:48:16
スコープが外れたときにfinalizeが呼ばれるようにすりゃいいんだよ
そうすりゃガベコレでも問題ないし、メモリコンパクションで安定度最強じゃないか
0044デフォルトの名無しさん2005/09/02(金) 22:53:58
>>31
まさに論理的思考能力が無い奴がコミュニケーションがとれないことを意味するものだな。
論理的に考えろと言われるとすぐに理屈っぽいとか言う奴は根拠を示せないため、
論理的に考える奴＝理屈っぽい奴という数式が脳内で勝手に成り立ってしまっている。
文系で理系嫌い、理系が苦手な奴やフィーリングが大好きな女にはなぜかこういう奴が多い。

順序立ててしっかりと理論武装していないためまともな会話ができないと。


0045デフォルトの名無しさん2005/09/02(金) 23:16:02
>>44
数学の証明に類似しているが、理論づけってのは
一歩一歩確認しながら階段を上るようなもので、どんなむずかしい問題でもその一歩自体
は、確からしい、自明のことで成り立っている。
複雑な思考になれた人間なら3,4歩先を一気にかけあがることができるけど
そうでない人は同じことをしようとして逆に混乱してしまう。

個人的な経験なんだが、大学では、周りの連中は皆理解力のある奴が多かった。
それが災いしてかどうも自分は説明べたになった気がする。
3,4歩先の理解を知らず知らず相手に求めてしまってるからかもしれない。

0046デフォルトの名無しさん2005/09/03(土) 00:29:10
>>41
いつ実行されるか分からないと困るような後処理をデストラクタに書
くのが悪習慣。そもそもオブジェクトの寿命と必要な後処理を行なう
べきベストなタイミングが一致するとは限らないし、「プログラマの望む
タイミングで必要な後処理を行なうためにデストラクタを実行させる」
ためにプログラマが費やすべき努力は、「プログラマの望むタイミング
で必要な後処理を行なうための適当な関数を呼び出す」ためにプロ
グラマが費やすべき努力となんら変わるところがない。

ついでに言えば、デストラクタから必要な後処理を行なうための関数
を呼び出すことはできるので、それも書いておけば、GC有りなら最悪
の場合でも、いつか後処理が行なわれると期待できる。GC無しだと
オブジェクトをリークしてしまうと後処理が未来永劫実行されないはめ
になる。

>>43
オブジェクトの寿命がスコープと結びつかない場合にはどうするの？
0047デフォルトの名無しさん2005/09/03(土) 00:33:20
>>46
finalizeを実装しなければ良い。
というかスコープを外れたときのメソッドを用意しろってだけだけどね。
0048デフォルトの名無しさん2005/09/03(土) 03:24:01
>>38
グラフ構造でしかも別のデータ構造からも参照されたりとか本質的に参照の管理
が難しい場合はどうするの?
0049デフォルトの名無しさん2005/09/03(土) 04:01:23
class Node
{
unsinged m_ref;
Node() : m_ref(0){}
~Node(){ free resources; }
void Refer()
{ m_ref++; }
void Release()
{ m_ref--; if ( m_ref==0 ) delete this; }
Node* pOther1;
.....
Node* pOtherN;
};
って感じにして、ほかのNodeのポインタを得るたびにRefer()
してやって、参照しなくなったらRelease()を明示的に呼び出すというルールをつくる。
参照が0になったNodeは自動的に消滅する。
まあ要するにCOMですな。Nodeがメモリ以外のリソースをもっててもちゃんとデストラクタで解放できる。
0050デフォルトの名無しさん2005/09/03(土) 04:10:56
レファレンスカウンティングは広義のガベジコレクション
0051デフォルトの名無しさん2005/09/03(土) 04:19:21
まあ、そうなんだが非GC環境化でもGCのようなことはできる、ということ。
さらにGCより優れている点は、リソースの解放をもっとも効率的に行える、という点。
リソースを誰かが手放さない限り、ほかの誰かが利用できない、という状況のときなどは
オブジェクトがDeleteされた瞬間、時をおかずリソースを解放するのが望ましい。

逆に、GCではこういうことはできないのじゃないか。
0052デフォルトの名無しさん2005/09/03(土) 05:39:10
だが循環参照に対応できないわけで
0053デフォルトの名無しさん2005/09/03(土) 11:57:54
何度か出てるがGCの利点はメモリコンパクションの一点だけだってば。
0054デフォルトの名無しさん2005/09/03(土) 13:09:12
ポインタの先にある領域が動的に確保したのか静的なのかの区別が不要というのは案外大きい。
こいつはfreeしていい、だめ、の区別をフラグで持つのは面倒だが、
何でもかんでもmallocして渡す、というのもそれはそれでどうかと。
(といいつつ、俺は何でもかんでもmallocしてるが)

あと、メモリ管理とその他の資源管理をいっしょくたに考えるのは
あまり適切ではないように思う。状況によっては同じように考える
ことはできるけど、全てそれで押し通せるわけでないのは明らかなので。
0055デフォルトの名無しさん2005/09/03(土) 15:51:12
perlだったらjavaと違って変数がスコープから外れたらすぐデストラクタ呼ばれるよ。
仕様かどうかはしらんが挙動はそんなんだった。
0056デフォルトの名無しさん2005/09/03(土) 16:20:33
参照カウントでやってるんでしょ。
0057デフォルトの名無しさん2005/09/03(土) 16:32:47
だが循環参照に対応できないわけで
0058デフォルトの名無しさん2005/09/03(土) 17:14:30
perlは元々参照カウンタ + GCなんだが
0059デフォルトの名無しさん2005/09/03(土) 17:20:16
finalizeって使ったことある？
なんのために使うの？
0060デフォルトの名無しさん2005/09/03(土) 17:22:48
いやでも循環参照だったらGC環境下でも
オブジェクトは破棄されないんだから非GCと問題は同じじゃないか。
0061デフォルトの名無しさん2005/09/03(土) 17:30:21
60 名前：デフォルトの名無しさん[sage] 投稿日：2005/09/03(土) 17:22:48
いやでも循環参照だったらGC環境下でも
オブジェクトは破棄されないんだから非GCと問題は同じじゃないか。

0062デフォルトの名無しさん2005/09/03(土) 18:07:02
どういう時に解放すべきでしょうか？
いらなくなったから早速というのではなにか違う気がします。
0063デフォルトの名無しさん2005/09/03(土) 18:08:02
シングルタスクOSじゃないなら即解放の方が
他のアプリに優しい
0064デフォルトの名無しさん2005/09/03(土) 18:49:43
>>59-63
最低限の会話できるレベルになるまでROMってろ
0065デフォルトの名無しさん2005/09/03(土) 20:56:11
ROMってるだけじゃダメだと思うぞ。穴だらけの耳囓りがせいぜい。
0066デフォルトの名無しさん2005/09/05(月) 18:28:50
C言語で(＋＋ではなく)BigIntegerに当たるライブラリってある？
0067デフォルトの名無しさん2005/09/05(月) 18:44:43
GMP
0068662005/09/05(月) 20:01:15
>>67
ありが㌧
0069デフォルトの名無しさん2005/09/09(金) 08:48:19
デストラクタ否定派へのヒント：AUTOMATION
0070デフォルトの名無しさん2005/09/12(月) 02:48:09
こんなところでしょうもない議論しないで、無い知恵しぼって
BSDライセンスかApacheライセンスのカスタムGC作ればいいだろ？
グダグダいっても何にも解決しないぞ？
0071デフォルトの名無しさん2005/09/12(月) 14:36:51
boehm GCはBSD likeなライセンスだモナー。俺はこれで十分だモナー。
mallocに毛の生えた程度のリファンレンスカウントなGCなら半日もあればデバッグまで終わるモナー。
つい先日作ったモナー。(上の台詞と矛盾があるのは気にするナー)
メモリプール型のメモリ管理ならApacheライセンスのapr使えばいいモナー。
結論として、このスレは雑談以上のものにはたぶんならないモナー。
0072デフォルトの名無しさん2005/09/12(月) 23:43:04
NSAutoreleasePool最強
0073デフォルトの名無しさん2005/09/17(土) 13:28:12
>>72
潰しがきかない。
0074デフォルトの名無しさん2005/09/17(土) 17:52:05
おれの処理系はセルオブジェクトだけGC対象
0075デフォルトの名無しさん2005/09/22(木) 12:08:55
>>72
Delpihのプロジェクトに同じ仕組のクラスを導入してみた。
スレッドとの相性が最悪だと後で判った。

GCがメモリ以外のリソースの後始末に使えないのは事実だけど、コーディングの負担軽減になるのはたしか。
特に、例外安全を徹底したい場合。

参照カウンタは言語に組み込めないと効果は限定的。
最初スマートポインタが神だと思ったけど、メソッド内でthisを他のオブジェクトに渡そうとすると破綻する。
例えば、メメントパターンを使うと発生する。
参照カウンタをオブジェクトに持たせると解決するけど、その時は手遅れだった。

boostあたりで将来の標準ライブラリ導入前提でGCを用意して欲しい。
もめるだろうけど。
■ このスレッドは過去ログ倉庫に格納されています