mallocとfree

fj.comp.lang.cなどで話されている「mallocとfree」の内容に対する
感想や考えを述べるスレッドです。

fjで話されている「mallocとfree」というのは、要約すると
「mallocで確保した領域は終了時に自動的に開放される(らしい)のだから
よほどの事情がない限りfreeする意味が無いのではないか?」
ということを話し合っていました。(違うようでしたら補足をお願いします)

私としては「freeしたくない」人がいろいろ理屈をこねてるだけ
のような気がしてならないのですが・・・

書いてるコードの性質にもよるだろうけど...
20時間ぐらい走って それからメモリ不足で落ちるのは勘弁して

free しないとどんどん使用可能メモリ減っちゃういそうです
スワップファイルが大きくなるのもいやだし
クラスの定義でオブジェクトが free しないのは
なんか嫌な感じがしますが・・ってこれはＣ＋＋の話ですね

関係ないことで申し訳無いんですが、fjの過去記事って、
どこにあるんですか？

gooで検索したら過去記事を保存している所がありました。

mallocとfreeのスレッドは

http://news.dinf.ne.jp/news/fj/comp/lang/c++/thrd6.html
から
http://news.dinf.ne.jp/news/fj/comp/lang/c++/thrd23.html

まであるようです。かなり長いです(^^;

http://news.dinf.ne.jp/news/fj/comp/lang/c++/thrd5.html#00243

すみません、ここにもありました。けれど、大元の記事は見つけることができませんでした。

使わないなら、なんのために free があるのって思うけど・・
静的配列も解放とか、わけわかんない意見もあるし
実装と論理を混同してる気がする。
ＯＳを記述することもできる言語に
ＯＳが処理することを前提とした処理をさせるのは
ナンセンスのような。

サンキュー。参考にします。

すまん、わかりづらいな。
タスク終了時にＯＳがメモリを解放するとは限らないのに
解放してくれるという、処理系依存な前提で書くのは
ナンセンスでは、ということです。

mallocしたものはfreeする でいいじゃないの。

mallocがどっからメモリを割り当てるかなんて、知ったこっちゃない(=依存すべきでない)し
freeがどこにメモリを返すかなんて、これまた知ったこっちゃない。

malloc/freeを使う人が知るべきことは、どこからともなくメモリが割り当てられて、使い終わったら返す、ということ。
以上 おしまい。行儀よくできたらいい子いい子。

age

fj で話されているんだから、fj に行け。

もともと
-------------------
C言語の本をにはたいてい
mallocしたメモリーをもう使わないなら放っておけば
終了時に自動的に解放されるので明示的にfreeしなくても良い
と書いてあるのですが、先日ある雑誌を見ると
明示的にfreeしないとメモリーリークになる
と書かれていました。どちらが正しいのでしょうか。
-------------------
って書き込みがあって、「いやそんなことはない。Free すべきだ」
「環境によってはほっておいても良いよ」って話が続いているだけ。

元々の「free をしなくてもよい」と書かれた文献に関しては
元質問者は返答なし。たぶんびびって逃げたんだろう。

不毛な議論だ

弱点：ガーベッジコレクション

なんでOS側がプログラム終了時点ですべてのリソースを解放出来ないの?
　なにが難しいの？(自分なら簡単にできる!って意味じゃないです)
OS組んだことがある人 or 詳しい人。教えて！

一応C/C++にもガベージコレクターライブラリってのがあるよ。
w3mくらいしか実用例を見たことがないけど・・・
あと、Apacheのモジュール作成ライブラリにはプールというそれに近い(のか?)
概念がある。

>15
開放したく無い時ってのもあるでしょ？

弱点というよりは特徴なんだろうな。＞GC
長所と短所があるからね。

>15
Ｃの実行環境はＯＳが必須ってわけじゃないし
あえて定義してないのかもしれない
malloc/free で一歩踏み込んでそこまで定義すると
ＯＳの仕様を限定することになりますから。
それはＣの仕事ではない、と。

仮にOSが完全なリソースの開放を保証したとしても、
第三者がそのソースコードを見た場合、freeを書かなかったのか、
freeを書き忘れたのか、よほど単純なプログラムじゃない限り、
調べることにかなり労力が必要ですね。。。freeを書くべきでしょう。。。

とりあえず、C++に移行してmalloc()を使用しないようにしましょう。

http://www.amy.hi-ho.ne.jp/~lepton/program/p1/prog121.html
http://member.nifty.ne.jp/maebashi/programmer/c_yota/malloc.html

fjの記事を見た人の感想が書かれています。

>22
サンキュー。勉強になるなぁ。

17&19 さんきゅ。

でも、なんかの本で確かに「OSがプログラム終了時点で解放してくれる」
ってのを読んだんだが、、、あれは嘘ってことだよね？
　ちなみにfreeはしっかり書く派です。

PCの"普通の環境や状況"では、プロセスが終了するときに、そのプロセス用に確保されたメモリは解放されるよ。
「例外なく」「言語で規定されている」というのは間違いだけど。

1さんが紹介している、http://member.nifty.ne.jp/maebashi/programmer/c_yota/malloc.html
の、Storageによる破棄と、似たようなことが、プロセスが終了するときにおこると思うといいのかもしれない。

でも、malloc/freeとは直接関係ないような。

「グラフの破棄がめんどさいよぉ。」って気持ちなんだろうな。きっと。
でもって、そこまで苦労して、破棄してどうするの。とか。

または、プロファイラで調べたら、データ構造の生成に30%処理に50%
データ構造の破棄に20%もかけてるぞぉ...
どうせ、プログラムは終了するんだから、データ構造なんか破棄しなくてもいいよね？？
とか、そんな気持ちなのかな。

何度も呼ばれる関数とか何度もインスタンス化→破棄を繰り返す
クラスとか作ること無いんでしょ。

それなりのクラス設計するようになったらfreeを終了時に
やってもらえばいいなんて発想は無くなると思うけど。

JAVA House MLでJAVAでガーベッジコレクションを自動的にやらせ
ずに明示的に malloc と free ができないかという議論があったな。

finalizeのタイミングを制御したいってこと ?

予期しないタイミングでガーベッジコレクションされて、
ガーベッジコレクション中の他の処理が遅くなって困ると
いうような事だったと思います。解決策は、system.gc()
を事前にやっておくということだった思う。

> system.gc()を事前にしておく
もっともな意見だ。
でも、当たり前過ぎて、ちょっと残念。

あげ

openしたらcloseする
allocしたらfreeする
当然のことじゃん？

free_all()みたいなことができたら便利かもね。
ツリーを破壊するときなんかは...

ツリーって普通親を殺したら子も道連れになるように作らない？

sorry＠｀ my front end processor has wrong.
so＠｀ where is gabage collection library on internet?
someone plz tell me the url to get it.

ガーベージコレクションの話じゃなくて、ツリー構造の親のデストラクタ内部で
ツリーにぶら下がっている全部の子のデストラクタを呼ぶように作るという事です

ガーベージコレクションの技術的な内容については Perl本とかで実際にインタプリタ
でどう実装されているかの例が覗けますよ

いやルビー本だったか

　freeしなくてもいいなんていってる連中は、
その程度のプログラムしか作ったこのがないレベルなので、
無視して構いません。

木は普通子連れで壊しますね〜。
DAGや辺リスト表現のグラフなんかは、ちょっとめんどくさいよう
な。あんまり必然性はないけど。
サイクリックな参照をする、データ構造だと、参照カウンタを
使った単純なテクニックだと、中ぶらりんになるのが気持ち悪い。
＃もちろん free()不要論者の方には関係ない話でしょうが。
楽してそこそこの効果を狙うとなると、自分でmark&sweep法
のGCを作ることなのかなぁ。

>サイクリックな参照をする、データ構造だと
あんまりややこしい時は推移論包だから
ね、n-aryや有効グラフは使わないなぁ。
事例にちょっと関心がでてきたな。
有効グラフを使ったソースとしてはGNUflex
だな。とりあえず。

Boehm GCはどうよ?

http://ei5nazha.yz.yamagata-u.ac.jp/~aito/gc/gc.html

Boehmは回収し損ねるとあるわけだから、実験的な物。
使うとすれば登録の関数を持つ「コーノ」式か
「プール内アロック」だろうね。
後者は作ってみたけど結局使う機会がない。配布しようかな。

関数内ローカルなオブジェクトだけでも自動的に廃棄してくれると助かる。
Ｃ＋＋ならそれが可能だが、Delphiはそれが出来ないのが不満。
Try...finalyをいちいち使わなければならない

C++でコンストラクタ内で例外が起こったとき、そのオブジェクトの
デストラクタが呼ばれないというのを最近まで気づかなかった。

お願いしますm(_ _)m