main以外★mallocの後にfree不要と言うバカいるの？

1 ：2012/11/13 〜 最終レス ：2013/01/17

前提１：一般的なC言語（GC搭載していない）
前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある

これがメモリリークするのは当たり前の話で、
mallocをしたらfreeするのは当たり前。
free不要論とは一体何だったのか。
天邪鬼（バカ）が言葉尻を捉えていただけではないだろうか。
まつもと ゆきひろもそのバカの一人だったらしいね。
例外中の例外を除いて、mallocをしたらfreeは必要。
これが真の答えだろう。

2 ：

10年前の俺を見ているようだ

3 ：

昔のアプリはサーバーなんてものは考えられておらず
アプリ（CUIしかない）は実行したらすぐに終了していたんだよ。
だからfreeしなくてもいいとかいう間違った考え方が生まれた。

4 ：

exitで脱出したい時にもいちいち手間掛けてfreeすんのか、って話だとか聞いたけど。それなら
確かにfree要らんわな。
freeしても大抵マークするだけだしプロセス終了時に開放されるからfree不要、って話の方には、
基本的に賛同しないけどな。してもしなくても変わらないケースも多いが、変わるケースも少なく
ないし、freeを省略する利点も無い。実行形式をとことん小さくしたい時くらいかね。

5 ：

>>1
つか、その前提条件はmalloc-free論争のときのと違うし。

6 ：

>>3
基本的に終了しないアプリなんて、それこそC言語が生まれる前からあるだろ

7 ：

free地獄
a = malloc(10);
if (error) {
free(a);
return;
}
b = malloc(10);
if (error) {
free(a);
free(b);
return;
}
c = malloc(10);
if (error) {
free(a);
free(b);
free(c);
return;
}
process();
free(a);
free(b);
free(c);
return;

8 ：

a = malloc(10);
if (!error) {
　b = malloc(10);
　if (!error) {
　　c = malloc(10);
　　if (!error) {
　　　process();
　　}
　　free(c);
　}
　free(b);
}
free(a);
return;

9 ：

>>8
真のfree地獄
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.10.1.list

10 ：

>>1
> 前提２：main関数は除く
> 前提２'：exit関数を呼び出す場合を除く
これを除外しないのがfree教信者。前提が違う。

11 ：

>>7-9
それはfreeの問題じゃなくて書き方がアホなだけだ

12 ：

>>7=>>1だったら大爆笑

13 ：

少々リークしたってプログラムが終われば無かったことになるから問題ない←free不要派

14 ：

ジョブから呼ばれる小さなルーチンを沢山書いてきた
UNIX系の人にメモリーに限らずリソース開放軽視してる人多かったな
PC育ちの自分にとってはそんな書き方したらマトモに
動かなかったから信じられなかったけど。
　プロジェクト全体のリソース管理状況をチェックする担当になった時に
リークチェッカーに引っかかった箇所を、それぞれの担当者に
修正お願いするんだけど、サーバーとの通信部分を担当してた
男版お局さんみたいな人に、DLL解放時にリークしてるところが
あるから修正してくださいって頼んだけど最後まで無視されたな。
実際はプロセス内で何度もロード・アンロードするところだから
問題有ったんだけど、事を荒立てないように見なかったことにした。
立場の弱い人間には強制的に修正させたけどね
韓国の会社が作ったUNIX用の結構大きなソフトのWindowsのポーティングも
やったけど、それもリークが酷かったな。
あの当時、Windowsが糞OSとか叩かれてたけど、ちゃんと書いたプログラムは
ちゃんと動くのを身にしみてたからMSが気の毒だった。
どんな優秀な人でも、一度身についた悪習は中々直せないもんだよ

15 ：

>>14
お前、malloc-free論争のこと全然知らないだろ。
知らないなら黙っとけ糞が。

16 ：

昔の自称"議論"が永遠に有効だと思ってる人って居るよね。

17 ：

> main関数は除く
なぜ？
main関数はfree不要なら、他の関数でも同じじゃないの？

18 ：

そりゃmainも除いたらだめよ
mainでmallocして使われなくなってもそのあとまだまだ続かないとも限らないんだから

19 ：

「関数終了時」を話題にしているのは明白だろ。バカは死んでくれ。

20 ：

mallocしたらfreeする。
そんなのは当然だ。
ただし例外があるというだけの話。

21 ：

>>20
その例外がさも一般的なことであるかのように
話をしていたのが、free不要論なんだよなｗ
今の時代、free不要とか言い出したら
キチガイ認定されるだろう。

22 ：

「free不要論」とやらの正体が分かんねぇんだよな
A「プロセス終了時に開放してくれるOSでは、exit()を掛ける前にもfree()する必要は無い」
B「free()しなくてもどうせ変わらんから要らない」
どっちの論理なのかのソース出せよ
Aだと思い込んでる奴と、Bだと思い込んでる奴と、言い合っても話が通じるわけねぇだろ

23 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

24 ：

>>23
ここまで来てからそれか。
敗北宣言と見なされるぞｗ

25 ：

>>20
freeするのは当然じゃないよ。
「freeしなければならない場合がある」というだけでそれ以外は不要なんだが、「それ以外」がどういう
ときなのかわからない人が「freeするのは当然」と思考停止してしまうのが論争になった原因。

26 ：

思考停止してるのはお前
どうせド素人なんだろうけど

27 ：

>>25
思考停止するからダメだって話なのか。マジかよ。激しくダサいなｗ
心理学者かよｗｗｗ

28 ：

むしろmallocが不要

29 ：

普通は「メモリの解放？何それ、おいしいの？」ってなるようなコードを書くんだがな。

30 ：

free()しない奴にライブラリや共有オブジェクト作らせたくないわ
GCが働いてくれる言語でバグ出さないようにしてもらえればそれで十分
こっちくんな

31 ：

未だにＣ言語で型保証なしのmallocかよw

32 ：

>>25
で、思考停止しないで考えて出した答えは
やっぱりfree必要なんだろ？
そのソースを教えてくれ。

33 ：

>>22のAに反対の奴とかBに賛成の奴とかっているの？

34 ：

スレッドの走行中に、
たとえば、スレッドがファイルを開いたり閉じたりしている場合、
しかも、スレッドを止めないで親が終了した場合、スレッドのオブジェクトは、解放されますか？

35 ：

環境依存

36 ：

※この自動車は連続30分走行するとブレーキが利かなくなります。
　定期的にエンジンを再起動してください。

37 ：

ニュースグループかよw

38 ：

>>36
※この自動車は連続○分エンジンブレーキで走ると
　エンジンがフリーズして二度と動かなくなります。
　定期的にエンジンを空吹かししてください。
混合油2スト時代の常識ｗ

39 ：

mallc()/free() では信者を巻き込んで熱くなる議論も、これをfopen()/fclose() に置き換えるとまったく結論が異なるようだ。
「fclose() しなくてもOSがディスクリプタを回収してくれるから無問題したがってflocse()不要」という主張はあまり耳にしないのだが？

40 ：

>>39
いやその話だって処理系に依存することには変わりはない訳で、本質は同じでしょ

41 ：

ここでもバカ晒してるのか。
↓ ここにfcloseしてないJスがいますよ。 ｗｗｗ
http://codepad.org/mLtuxDOF

42 ：

>>39
OSが回収するのは「ディスクリプタ」じゃないけどな

43 ：

>>39
そうか？ むしろそちらの方を良く聞いたが。
使い捨てのスクリプトなんかは close しないのも結構あるんじゃないか。

44 ：

>>42
ふむ。確かに一つのディスクリプタを複数のプロセスで共有しているときに、ひとつのプロセスが終了したからといってディスクリプタ自体を閉じてしまっては一大事ですね。
このあたり疎いのでもしよろしければ参考本を教えてください。
>>40 >>43
んー、最近はclose()/fclose()論争をあまりきかないので‥‥こんど煽ってみよう‥‥
>>41
みつかったか :-)

45 ：

Cでgotoを使っていいか悪いか、にも似てるな
使っていいとこはあるけど基本使うなよ、でも無理に使わないことも無いよ、っていうあれ

46 ：

今となっては過去の論争だからねぇ。
今だと誰もがfreeすべきだと答えている感じなんだが、
昔はなぜかfreeしなくていいのが多かった感じがする。
しかも詳しい人ほどfreeしなくていいと言ってるみたい。
やっぱ昔はfreeするコストとかまで気にしていて
綺麗なコードよりも、技巧的で速いコードが好まれていたってことかねぇ。

47 ：

単にUNIXとかは短いプログラムを
ジョブからプロセスキックする様なシステムが多かったから
いちいち解放しなくてもOSが勝手にやってくれるじゃん
みたいなことじゃね？
そもそも、昔のプロのプログラマーの環境はリソース足りなきゃ
ハードを増強すりゃいいだろみたいな考えだったし。
そして、昔はUNIXプログラム＝プロのプログラム
パソコンプログラム＝アマチュアみたいな感じで下に見る傾向が強かったから
UNIX文化＝常に正しいみたいな根拠のない流の議論になってたんじゃないかな

48 ：

そういう人たちってもう死んだの？
当時そう言っていた人が
今は考えを改めたのか知りたいんだけど。
今はfree不要論者全然いないし。

49 ：

そういう人たちもfree不要って言ってたのはUNIXコマンドみたいなメモリ常駐期間の短いものを対象に言ってただけで
今みたいな何時間も何日も起動しっぱなしのプロセスについてはfree不要とか言わないよ
それに昔はメモリをそんなに積んでなかったから設計時に全てメモリ使用量を計算済みだったから
プログラムの最初に大方確保してそれを使ってたからね
今みたいに任意のタイミングに動的にメモリ確保とかそんな贅沢できなかった

50 ：

>>48
おっかしいなー、
宿題スレではfree()信者はそれこそ｢信者」扱い、free() を省略できなければどんくさい、くらいの価値観が通っているんだけれども。
ダングリングポインタや、手放してしまって金輪際free() できない領域（これなんていうんだろ？）が発生しなければ OK くらいが落としどころになってる。

51 ：

>>50
だからそれ、プログラムが完全に終わる直前の話でしょ？
プログラムのすべてをmainでやってるのならともかく、
普通関数の形にするよね。その関数はどういう呼ばれ方をするか
わからないものとして作るから、mallocしたらfreeするよね？
結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
freeを省略できる条件を明確にして欲しいよ。
あ、もちろんエラーで強制終了する場合は除く。

52 ：

>（これなんていうんだろ？）
リーク

53 ：

>>50
あれはfree教教組が教義を押し付けたけど、その教義がマヌケという事実を
指摘されて火病ってるだけ。
>>51
> プログラムのすべてをmainでやってるのならともかく、
> 普通関数の形にするよね。その関数はどういう呼ばれ方をするか
> わからないものとして作るから、mallocしたらfreeするよね？
関数の形になってても省略可能な例
main()
{
create_object();
print_object();
}
> 結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
* 寿命がmainに等しいシングルトンなオブジェクトは現実的にも普通にあるし
　よく使う。このようなオブジェクトはfreeしなくてもよい。
* BoehmなどのGCは「これまでにアロケートしたものをすべて解放」なんてい
　うインターフェースはもっていない。ルートポインタをNULLにして回収を
　試みてもコンサバティブGCなので回収できることは保証されていない。
　そしてBoehmを利用しているプログラムは現実的にたくさん存在する。
> freeを省略できる条件を明確にして欲しいよ。
自分で考えろ。それを他人に押し付けるな。

54 ：

>>53
＞関数の形になってても省略可能な例
ん？簡略化しすぎているんじゃない？
＞シングルトンなオブジェクト
静的にもつほうが多いようなきが
BoehmGC がすべて開放するようなインタフェースを持たない、としてもそれはGCだからでは？
GCにたよらず自力本願なC++において、デストラクタを定義しなくともよい場合がある、という主張はあまりきかない。
＞教義がマヌケ
正常系でもfree()しないのはねえ‥‥

55 ：

>>53
お前、create_objectの実装しってんの？
関数使う側は内部の実装のことを気にしないものだよね。
create_objectがもし一時ファイルとか作っていたらどうするの？
delete_objectしないとだめだよね。

56 ：

>>54
教組登場。バカは引っ込んでろ。ｗｗｗ
>>55
> お前、create_objectの実装しってんの？
知ってるよ、delete_objectが用意されてない事も。
「mainで全部やらない」という事への反例だから。

57 ：

即ち...
テキストファイルを閉じてもメモリを開放しないマルチテキストエディターが作りたいということか...

58 ：

今さらCでテキストエディタは作りたくないな

59 ：

>>46
単に
「どんな場合でも確実にリソース解放できるわけじゃないから、
　実用上問題になるケースだけリソースを開放すればよい」
というだけ。

60 ：

何が「即ち」なんだろう。free教信者の思考停止は救いようがないな。

61 ：

> 教組
この手の奴は総じて日本語もダメ

62 ：

結局、
・mallocしたものは必ずfreeで開放するべき
・メモリリーク障害を起こさないようにするべき
の違いでしかないんだけどね。

63 ：

どうでもいいけどfree不要を唱えるバカとは一切仕事上で関わり合いたくない

64 ：

どうでもいいけど、いかなる場合もfreeせよと主張するバカとは一切仕事上で関わり合いたくない

65 ：

どうでもいいけどC使いたくない

66 ：

>>62-63はもっともな意見だけど、>>64も無視は出来ないよね。
私も>>64のいわんとすることが何となく分かります。
free();しなくて良い時は、
　(1) 書く人が「しなくて良い」ことが分かっている
　(2) 他人にソースを引き継ぐ(または解析されることがある)場合は、
　　　余計な解析をさせないためにコメントに明記する
これが前提にあった上で、free();しなくても良いと思いますよ。
で本題ですが、上記(1)について。
「どういう時にfree()しなくて良いのか」
私が思いつくのは、
　1. malloc()は最初に1度行われ、main()を抜けるとシステムが
　　 代わりにfree()してくれる
　2. malloc()は最初に1度行われ、main()は抜けない。
　　 無限ループ+電源断か、シャットダウンイベントによって
　　 システムが終了する組み込み系など
他に具体例、何かありますか？

67 ：

free()のコード読んでからもの言え

68 ：

今時freeするなんて
古いよねー

69 ：

mainだったら関数が終わるときにfreeをしなくてもいいけど、
将来外部関数としてそのmainが再利用される可能性が
ありうればfreeの処理も書いておく

70 ：

まぁ、そゆこっちゃ
喧嘩するほどの話でもない

71 ：

mallocでNULLが返って来たとき、ろくに出来る事も無いしexitで即死しようって場合は
すでに確保したメモリをfreeしなくても良いよね？

72 ：

環境依存

73 ：

余談だけど、malloc()のmanpage によると、malloc()でNULL以外が返ってきて
正常動作するなと思っていても、死ぬことあるんだね。
> バグ
> デフォルトでは、Linuxは楽観的メモリ配置戦略を用いている。
> つまり、malloc()がNULLでない値を返しても、そのメモリが実際に利用可能であることが
> 保証されない。これは本当にまずいバグである。システムがメモリ不足状態になったとき、
> 悪名高いメモリ不足解決器(OOMkiller)によって一つまたは複数のプロセスが削除される。
> 突然あるプロセスが削除されるのが望ましくない状況で使用されていて、しかもカーネルの
> バージョンが十分に最近のものであれば、このメモリを割り当て過ぎる動作(overcommittingbehavior)
> を以下のコマンドで無効にできる。
>　　# echo 2 > /proc/sys/vm/overcommit_memory

74 ：

>>56
> 知ってるよ、delete_objectが用意されてない事も。
へんな話だな。
世の中の関数に、リソースはメモリの確保しかしていません。
終了時に解放処理をしなくても大丈夫ですって仕様に書いてるの無いでしょ。
どうせ自分が作った関数だからdelete_object呼ばなくても大丈夫って
知ってるとか言うつもりなんだろうけどさ、そんな話はしてないの。
他人が作った関数を思い浮かべればいいよ。
その関数がmallocをしてメモリを確保するのであれば、
逆にfreeする関数も用意している。
他人が作ったもので、他人がメンテする。だから実装がどうなってるかは考えない。
中の実装を見て、使用者側がコードの使い方変えるとか馬鹿のすること。
そう思うよね？

75 ：

処理系依存は気にするのに
OS依存は気にしないんだなｗ
特定の処理系（OS）に依存したコード書くなよ。
OSが必ずメモリ解放してくれるとは限らないだろ。

76 ：

>>64
俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。
で、お前の意見は？
どういう場合に限ってfreeしなくていいと言う？

77 ：

7.24:
プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A:
その必要はない。まともなオペレーティングシステムならきっとプロ グラムが終了した時点ですべてのメモリを取り返すだろう。
にもかか わらず、個人向けコンピュータ(PC)の中にはメモリを取り戻すことが 確実にはできないものもあるようである。
ANSI/ISO C規格から結論つ けられることは、解放してくれるかどうかは「実装の品質がどれくら い高いかによる」ということだけである。
References:
ANSI Sec. 4.10.3.2; ISO Sec. 7.10.3.2.

78 ：

7.24:
クロスプラットフォームなのでまともじゃないオペレーティングでも動かすことがあるかもしれない。
プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A:
とうぜん解放する必要がある。

79 ：

>>77
不自然な答えだよな。
OSがまともであるならと
前提をつけて結論を書いてどうするんだろう？
そのあとでまともじゃない場合があると認めてるのにね。
で、最後の行で話をすり替えてる。

80 ：

標準ライブラリがまともである保証はあるんですかっ

81 ：

俺ならこう答えるかな。
Q. プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A. プログラム側でfreeしなくても通常はOSが解放してくれるので直接問題が起きることはありません。
しかしながらそのようなことを気にしなくていけないのであれば設計上の問題がある可能性が高いです。
ライブラリ自体がメモリ解放の責任をもっているのであれば終了時にメモリが確保されたままになることはありません。
ライブラリの使用者側がメモリ解放の責任を持つのであれば、適切な場所でメモリを解放してください。
それなりの規模のソフトであれば、終了間際までメモリを確保したままになることはないはずです。

82 ：

一つのファイルに対してある処理をするプログラムを作った。
簡単なツールなのでmain一つで終わっていた。
freeは必要ないということで省略した。
そのうち拡張されコードが増えていった。
さすがに見通しが悪くなったので関数に分けた。
でもfreeは必要ないということで書かなかった。
一つのファイルだけではなく、複数のファイルに対応した
でもfreeは書かなかった。
たくさんのファイルを処理した時、メモリが足りなくなった。
freeを書かないメリットはあったのだろうか？

83 ：

教義に従い倍の時間をかけて異常系にもfreeを記述していった。
異常系のテストケースが不十分だったのでフィールドでセグメントフォルトが発生した。
必死になってfreeを書いたメリットはあったのだろうか?

84 ：

>>81
＞Q. プログラムが終了する前に、確保したメモリを解放しなければならな いか。
俺なら
Ａ．開放しないことでたとえなにが起きても自分で責任とれるならやらなくていい。
わざわざfreeが用意してある意味は自分で考えなさい。

85 ：

>>83
じゃあ異常系でのみ省けばいいだろ。
今は正常な終了時の話だ。
いると認めたのなら、そういえ。

86 ：

異常系を考えないなんて、学生プログラマかw

87 ：

異常系は停止していいと答えがでてるってことだろ。
はい。この話はもう終わり。

88 ：

はあ?
お前ら、ライブラリがエラーを返したら即プログラム終了かよ。
素人PGはお気楽でいいな。

89 ：

またずれてる奴が来たね
相手にしなくていいぞ。

90 ：

>>83
信じるものは救われる

91 ：

環境依存だろ
これ以上書く奴は馬鹿かpンジー↓

92 ：

ウキキー（pンのおいらでも後片付けくらいするずら）

93 ：

newの戻り値はNULLチェックする必要ある？
例外で処理するのが一般的？
deleteするときもNULLチェック必要？

94 ：

>>93
new(std::nothrow)の場合はNULLチェック必要。普通のnewはstd::bad_alloc例外を投げるのでNULLチェック不要。
deleteについてはNULLチェック不要。

95 ：

むしろdeleteした後そのポインタにNULLを入れる行為に意味があるのかどうかのが気になるな

96 ：

>>76
俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。
で、お前の意見は？
どういう場合にfreeしなきゃいけないという?

97 ：

釣られないぞ(AAry

98 ：

>>96
手術中にメモリ不足で電力供給されなくなって患者を殺したらどう責任取るの？
お前の命じゃ全然足りないよ？

99 ：

そういう機器だとfreeしないんでｗｗｗ

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

OpenGLスレ Part19 (206)
NullPointerExceptionを「ぬるぽ」と呼ぶスレ6 (406)
バージョン管理システムについて語るスレ9 (312)
D言語 Part30 (915)
Visual Studio IDE環境 (568)
D言語 Part30 (915)
--log9.info------------------
藤本隆宏 (842)
【井浦新】 Part8 【ARATA】 (984)
竹野内豊50 (457)
筒井道隆…７ (358)
安藤政信　8 (492)
和田正人　3.5 (311)
高良健吾3 (897)
城田優18 (645)
小出恵介PART25 (388)
玉木宏　part151 (456)
高岡蒼佑　15 (246)
【熱く語る】　市原隼人　27　【熱い男】 (591)
□■□　上川隆也　その36　□■□ (229)
窪塚洋介さんて (869)
佐藤健　79 (207)
眞島秀和その４ (530)
--log55.com------------------
★2ch.scは何故失敗したのか
★クロール批判要望スレ
★削ジェンヌに文句ある人集合
★迷惑行為報告担当 - 小さな親切募集中 2
★2ch.scへの要望スレ Part3
★かっこう観測所
★スレ立て人キャップ
★2ch.scニュース系板観測所