mallocの後にfree不要と言うバカいるの?Part2

**デフォルトの名無しさん** · 2013/01/30(水) 21:38:37.44

fjの時代から10年以上に渡るmalloc/free問題について語ってください(^q^)

前スレ
main以外★mallocの後にfree不要と言うバカいるの?
http://toro.2ch.net/test/read.cgi/tech/1352812333/

**デフォルトの名無しさん** · 2013/04/13(土) 22:17:23.81

>>232
スレタイくらい読めボケカス

**デフォルトの名無しさん** · 2013/04/14(日) 00:08:23.17

移植性とかいっても今時free必要なOSなんて無いから

**デフォルトの名無しさん** · 2013/04/14(日) 16:39:02.13

そもそも俺freeしないとどう困るか理解してないから

**デフォルトの名無しさん** · 2013/04/21(日) 19:36:14.85

困るまで free してはならない

**デフォルトの名無しさん** · 2013/04/22(月) 04:31:27.17

環境依存

MS-DOSは、シングルタスク。
プロテクトモードで実行中にメモリでエラーで終了…
メモリ不足でもはやエディタも起動できないとか
リセットボタンをおすしかない

**デフォルトの名無しさん** · 2013/04/23(火) 00:17:07.69

freeしない奴は糞してケツを拭かない食糞民族と同じ。

**デフォルトの名無しさん** · 2013/04/28(日) 02:47:36.83

なんてことだ、俺たちは「どうせ風呂入ればうんこ落ちるし風呂入る前にうんこ拭かなくていいよね」派と戦っていたのか・・・

**デフォルトの名無しさん** · 2013/06/05(水) 12:38:51.14

exitすればおｋ

**デフォルトの名無しさん** · 2013/06/07(金) 12:06:28.26

ループ構造が完全にないなら開放不要だろ。

蓄積するから問題なんだから。。

＞free()した領域は再利用される
これメモリが分断されまくりの領域が本当に再利用されるのか？

**デフォルトの名無しさん** · 2013/06/07(金) 13:33:45.82

freeした時に隣が開いてれば一緒の領域にする、ぐらいは当然やってるよ。
仮にランダムにalloc/freeして、その結果「分断されまくり」になるというデータでもあるわけ？

**デフォルトの名無しさん** · 2013/06/07(金) 14:03:16.35

>>242
http://ja.wikipedia.org/wiki/Malloc
> IA-32アーキテクチャでのアロケータの実装には一般にヒープまたはデータセグメントが使用されている
> （セグメント方式）。アロケータがメモリを確保するとき、ヒープに未使用領域がない場合はヒープを拡張
> することでメモリを確保する。
>
> ヒープ方式はフラグメンテーションという問題がある。どのようなメモリ確保方式でもヒープではフラグメン
> トが発生する。つまり、ヒープ上に飛び飛びに使用中領域と未使用領域が存在することになる。優秀な
> アロケータはヒープを拡張する前に未使用領域を再利用しようとする。しかし性能問題があるため、リア
> ルタイムシステムでは代わりに「メモリプール」という方式を使う必要がある（特定サイズのメモリブロック
> のプールを予め用意しておく方式）。

**デフォルトの名無しさん** · 2013/06/07(金) 15:07:51.77

「 IA-32アーキテクチャでの」なんていう無意味な修飾を先頭に付けてる時点で、その執筆者は全く信用できない。

**デフォルトの名無しさん** · 2013/06/07(金) 15:33:53.68

>>244
君が信頼できる内容に書き換えてもいいんだよ

**デフォルトの名無しさん** · 2013/06/07(金) 18:12:08.82

mallocも実装したことないやつが語ってんのかよ。
アーキテクチャにほぼ関係ないだろ。Cで実装できるだし。

なにが君が信頼できる内容に書き換えてもいいんだよだアホが。

**デフォルトの名無しさん** · 2013/06/07(金) 18:16:11.80

>>246
お前がが実装したフラグメントしないmallocが、世界中の全てのプログラマで使われてるなら問題ないが、
フラグメントするmallocを使ってる人が多数いるってことに気づけ

**デフォルトの名無しさん** · 2013/06/07(金) 18:25:52.26

だからfreeしないのか？ｗ

どんな実装でもメモリ不足でぶっとぶわアホ。

freeしろ。

**デフォルトの名無しさん** · 2013/06/07(金) 18:32:07.16

> フラグメントするmallocを使ってる人が多数いるってことに気づけ

具体的にどのプラットフォームのlibcがそうなっているのか言ってみろよ。
多数ってもしかして、1, 2, たくさん、って意味かw

**デフォルトの名無しさん** · 2013/06/07(金) 18:39:12.06

>>249
glibc。
はい、論破。

**デフォルトの名無しさん** · 2013/06/07(金) 19:20:14.08

「俺様用語で定義するところのフラグメント」について語ってるなコイツw

**デフォルトの名無しさん** · 2013/06/07(金) 19:27:28.26

mallocは使い方を誤るとフラグメントが起きるから、
なるべく起きないようプログラムを設計すべきだな。

**デフォルトの名無しさん** · 2013/06/07(金) 22:13:39.69

>>249
glibc。
はい、論破。

**デフォルトの名無しさん** · 2013/06/07(金) 23:19:40.35

恥ずかしすぎる

**デフォルトの名無しさん** · 2013/06/08(土) 00:01:45.59

mallocの実装もできないようなゴミはgnucとかつかってんじゃねーよ。

glibc使ってるようなザコは、1度mallocで大量メモリ確保したあと自作のmallocで管理しろ。

**デフォルトの名無しさん** · 2013/06/08(土) 10:15:22.94

>>243
英語版から引き継いでるな。
しかも「すなわち」と訳すべき or を「あるいは」と訳してる（爆笑）

**デフォルトの名無しさん** · 2013/06/08(土) 13:13:50.33

>>255
真のザコw

**デフォルトの名無しさん** · 2013/06/10(月) 09:36:45.07

おれはループの中に含まれないmallocはfreeしなくてもいいと思うよ

**デフォルトの名無しさん** · 2013/06/10(月) 21:51:08.78

でも、free() しようと思えばできるけど、いちいち書くのはめんどくさいていう立場でしょう？

**デフォルトの名無しさん** · 2013/06/10(月) 22:10:56.15

freeして害になることは何一つない
freeしなくて良い条件を必死で探して屁理屈を垂れ流すのは、
1円安く物を買うために10km先まで行くようなもの
つまり、視野狭窄馬鹿の自己満足に過ぎない

**デフォルトの名無しさん** · 2013/06/10(月) 22:12:32.75

必死だな

**デフォルトの名無しさん** · 2013/06/10(月) 22:19:01.91

>>261
今どきそんな幼稚園レスして恥ずかしくないのか？
2ch黎明期じゃあるまいし

**デフォルトの名無しさん** · 2013/06/11(火) 00:04:55.16

>>260
散々既出だと思うけど、アプリ終了時の場合は自分でfreeするよりOSに任せたほうが早い場合もあるでしょ。
mallocしたメモリがswapされていた場合とか。

**デフォルトの名無しさん** · 2013/06/11(火) 10:36:17.87

>>260
「複雑なデータ構造のときに、mainからreturnする前に一生懸命freeしてまわるのがコードの無駄だし時間の無駄」

というのはうなずける。

**デフォルトの名無しさん** · 2013/06/11(火) 11:04:20.06

ただfreeするだけならともかく、構造体の中にポインタがあってそれを全部たどってると、
スラッシング起こすアプリとか、実際あるね。

**デフォルトの名無しさん** · 2013/06/11(火) 12:40:03.49

そういうプログラムは通常実行中も論外なのでは。

**デフォルトの名無しさん** · 2013/06/11(火) 12:41:14.78

mainからreturnの前のfreeは、自己満足に過ぎないよね

**デフォルトの名無しさん** · 2013/06/11(火) 14:22:12.07

>>266
実行中は仮想空間を食い潰してしまわないためにはfreeせざるをえないかもしれない。
Oracle JVM みたいにメモリ使用量を指定できるなら、それ使って実メモリのサイズに
抑えておくのが常道。

**デフォルトの名無しさん** · 2013/06/11(火) 21:45:13.42

>>266
まあ、必死に考えた無理矢理の例なので、暖かい目で見てやってください。

**デフォルトの名無しさん** · 2013/06/11(火) 22:09:58.38

具体的に反論できない人を生温かく見守るスレでつねw

**デフォルトの名無しさん** · 2013/06/11(火) 22:12:40.96

なら、具体例出してみなよ (w

**デフォルトの名無しさん** · 2013/06/12(水) 13:34:50.19

不定量だが必ず確保される。
プログラム終了まで必要。

以上の場合はfreeしないかもね。
単なる手抜き以上の理由は無いが。

**デフォルトの名無しさん** · 2013/06/12(水) 13:37:12.12

コンパイラみたいに1回走って終わりのプログラムなら、いらんよ。
最初のほうの手続きで確保して、後のほうでも使う、とかいうデータだと、
malloc/freeの対応が簡単じゃなくなるし。

**デフォルトの名無しさん** · 2014/06/08(日) 19:18:18.10

プロセスが終了したあとのメモリの開放って何かの規格に入ってんの？

**デフォルトの名無しさん** · 2014/06/08(日) 23:12:22.86

>>274
普通のOSならそうする、くらいとしか
MS-DOS ですらプロセスで取得したメモリブロックを回収にまわるから、それをしないOSは, MS-DOS 以下ということで

**デフォルトの名無しさん** · 2014/06/08(日) 23:20:13.12

POSIXの場合、メモリはプロセスにひっついてるものだから、プロセスが消えたら消える。

メモリはいいけど、プロセス間通信のための資源とかで、プロセスとは独立に生存する
ものについてはダメだから、注意する必要があるね。

**デフォルトの名無しさん** · 2014/06/09(月) 17:59:41.28

＞プロセス間通信のための資源とか
参照カウンタ見て上手くやってくれてるんじゃないの？

**デフォルトの名無しさん** · 2014/06/09(月) 22:41:25.12

man ipcrm

**デフォルトの名無しさん** · 2014/06/29(日) 22:57:20.87

mainだって普通の関数なんだから、プロセス起動時以外にもコード中で呼び出される可能性はある
つまりmainからreturnした直後にプログラムが終了してOSがメモリ回収するとは限らない

**デフォルトの名無しさん** · 2014/06/30(月) 00:10:01.85

重箱の隅つつくと普通ではないな。return省略していいっていう特別扱い

**デフォルトの名無しさん** · 2014/06/30(月) 09:54:32.09

(暗黙的なスタートアップから以外の)main()の呼び出しは未定義じゃなかったっけ?

**デフォルトの名無しさん** · 2014/06/30(月) 11:46:32.05

C++では明確に禁止。
Cでも、ふつうはやらないほうがいい。

そして、いずれにしろプロセスが終了すればプロセスが持っていた資源はOSが回収するので、
>>279 の言っていることは屁理屈にすらなっていない。

**デフォルトの名無しさん** · 2014/06/30(月) 22:02:19.05

なんか意味があるかって言われると何も言えないけど、
確かにCだとmain()を呼ぶことはできるんだね。
ttps://ideone.com/hII5Pp

**デフォルトの名無しさん** · 2014/06/30(月) 22:05:05.58

コードゴルフでループを書くよりもmainを再帰で呼ぶほうが短くなる、という技がある

**デフォルトの名無しさん** · 2014/06/30(月) 22:07:48.77

>>284
確かにmain()を再帰呼び出しして確認してもよかったね
というか、適当ソースだからどうでもいいけど、我ながらreturnなしのint hoge()って。。

**デフォルトの名無しさん** · 2014/07/07(月) 21:15:24.61

要約すると、メモリーが貴重な時代は終わった。終了が早いのが正義。freeいらね。

**デフォルトの名無しさん** · 2014/07/23(水) 06:53:50.72

>>282
普通は回収されるとはいえC/C++自体にその保証は無いけどね。>>274-275
>>286
自前でメモリ管理を再発明するなら別だが、確保と開放を繰り返す場合は必要。

**デフォルトの名無しさん** · 2014/07/24(木) 07:55:56.40

うん。言語では保証されてないね。
OS無しの環境を使ってるならね。

**デフォルトの名無しさん** · 2014/07/24(木) 21:52:53.95

hosted environment なら保証されてなかったっけ？

**デフォルトの名無しさん** · 2014/09/27(土) 01:05:41.54

例外的にfreeを使わないのが正しい判断でそうしてる場合であっても、freeを記述した
上でコメントアウトしておくとか、条件コンパイルでfreeを有効にも無効にも切り替え
られるようにしとかないと、まともなコードとして信用はできないな。

**デフォルトの名無しさん** · 2014/09/27(土) 01:46:12.43

ちゃんと free() できないくせに「free() を省略している」と主張するとか、面の皮が厚いですね

**デフォルトの名無しさん** · 2014/09/27(土) 09:52:04.78

LinuxはOSが完璧だからFreeの必要がないが、Windowsはバグが多いので
必ずFreeしなければならないと犬板で言ってた。

**デフォルトの名無しさん** · 2014/09/27(土) 10:27:03.26

>>292
Windows にバグが多いかどうかは別にして、必ず free すればいいと思ってる犬板の奴はアホとしか思えない

**デフォルトの名無しさん** · 2014/09/27(土) 11:23:46.58

エプロンおねえさん以上の知能の持ち主がなにかおしゃってますね

**デフォルトの名無しさん** · 2014/09/27(土) 14:31:25.00

Windowsで注意が必要なのはリソースとかで、
Linuxでも複数プロセスが共有する名前付きの資源とかは注意しなけりゃならんことに
変わりはない。

**デフォルトの名無しさん** · 2014/09/27(土) 14:42:06.10

free()すらめんどくさがるやつはプログラミングすんな
以上

**デフォルトの名無しさん** · 2014/09/27(土) 14:54:47.52

不要なOSでまで馬鹿正直にfreeしてたらクソ遅いだけじゃん
意味無いどころか害悪

http://cpplover.blogspot.jp/2014/09/cp4320039tb.html

**デフォルトの名無しさん** · 2014/09/27(土) 16:09:33.54

メモリの確保と開放がちぐはぐでバギーなことしたいならご自由に

**デフォルトの名無しさん** · 2014/09/27(土) 17:14:03.74

ちぐはぐにしないために、許容可能な場合は「freeしない」というポリシーを決めるわけです。
まったく何もわかってないバカということを露呈していただいてありがとう御座います。

一生そのレベルのバカでいてくださいね。使い物にならないプログラマが増えて爆死してけば、
使えるプログラマの給料が上がりますのでw

**デフォルトの名無しさん** · 2014/09/27(土) 17:15:50.18

乙女のポリシーかなんかですか？

**デフォルトの名無しさん** · 2014/09/27(土) 17:42:35.54

ポリシーって書ける俺かっけーって奴でしょ w

**デフォルトの名無しさん** · 2014/09/27(土) 17:48:52.13

流石バカ

**デフォルトの名無しさん** · 2014/09/27(土) 17:50:51.69

freeしないのは自由だし、必要ない場面があるのも確かだけど、イチイチそんな事例を列挙してポリシー()化する程のメリットがない

**デフォルトの名無しさん** · 2014/09/27(土) 17:51:04.65

freeが省略可能かどうか、事前あるいは局所的に判断できるようなあまり一般的ではない
ケースのためにわざわざ妙なポリシーを設定するのはセンス無いと思う。
あるいは、何か変更する毎に「前にここで省略したfreeがまた必要になってないか」って
気にしながらプログラミングするんだろうか。

**デフォルトの名無しさん** · 2014/09/27(土) 18:33:38.97

許容可能な場合は～
とか、ポリシーでもなんでもないだろ
どういう場合に許容可能とするかを書かないと意味がない
そのレベルの奴なので温かくスルーしてやりなよ w

**デフォルトの名無しさん** · 2014/09/27(土) 19:02:44.41

>>297が言いたいのは、Linuxは糞速いのでプログラム内から解放すると一日たっても終了
しない解放処理が、システムに任せると1nsで終わるということだと思います。
前から思ってたけど、glibcって糞ですよね。
libc5サイコーってLinux板で言ってました。

**デフォルトの名無しさん** · 2014/09/27(土) 20:22:12.59

cp使って大量で大容量のバックアップする人いるんだ
へー

**デフォルトの名無しさん** · 2014/09/27(土) 20:27:29.57

>>307
いますよー。
しかも、オプションなんて気にしないのです。

**デフォルトの名無しさん** · 2014/09/27(土) 20:38:54.53

デーモン類みたいな動かしっぱなしにするプログラムで、どんどんメモリを確保して手放さなかったら
困るけど、コンパイラみたいにどうせすぐ終わるプログラムで、今時なら100Mぐらいに収まるとかなら
どうでもいいだろ。その程度の想像力も判断力も無い奴が「温かくスルー」とか、能天気でいいよなw

あと、直接freeするわけじゃないけど、GCのある言語で終了前にGCが走るような場合、確保しまくった
メモリ空間を全部なめて回るからスラッシングが起きてマシンが劇重になることがある。
そんな場合も、本当に解放すべきリソースがあるのでなければ、とっとと_exitしてしまえばいい。

**デフォルトの名無しさん** · 2014/09/27(土) 20:47:14.49

必要かどうかを判断したり適切かどうかをチェックしたりする人的コストがムダ

**デフォルトの名無しさん** · 2014/09/27(土) 21:05:07.76

スマートポインタ作ればいいだけやで

**デフォルトの名無しさん** · 2014/09/27(土) 22:19:47.14

ぼくが書くような小規模のプログラムはfreeが必要なほどメモリ食わない
そしてメモリを逼迫するまえにプログラム自体が終了する
いつもfree書くけど書き忘れてもあんしん！！

**デフォルトの名無しさん** · 2014/09/27(土) 22:35:10.84

bashがfreeしないくらいだから、必要ないんじゃない？

**デフォルトの名無しさん** · 2014/09/27(土) 22:45:58.39

>>309
> どうでもいいだろ。

能天気乙 w

**デフォルトの名無しさん** · 2014/09/27(土) 22:48:39.13

今どきのOSではプロセス殺せば
ヒープなんて勝手に開放されるから
リソースのなかではある意味一番
リークしてもダメージの少ない
類いではあるよね

ヒープ以外のリソース開放には無力どころか
RAIIがしにくくなる分害悪にすらなる
GC付言語がこうまで持て囃されている
現実は不思議すぎる

**デフォルトの名無しさん** · 2014/09/28(日) 01:10:09.70

> 能天気乙 w

極端な話、メモリが100M越えたら強制終了でも構わないアプリ、なんてのもいくらでも考えられるが、
そういうのも全部「能天気乙 w」って攻撃するんだなw

ただのバカだった、で終了。

**デフォルトの名無しさん** · 2014/09/28(日) 02:36:06.63

>>299
「許容可能な場合は」←これ省略する馬鹿が居るからfreeしろって言われるんだよ。
>>303-304
開放処理が負荷になるケースのためにexit用の開放処理を一式再実装するとか、
通常の開放処理の中でexit確定フラグ見て開放処理をスキップするとか…面倒くさいね。
開放処理の負荷がヤバイことになるってケースが想定されない限りやりたくねぇわ。
>>309
cpの開放処理コストも普通に使う分には「どうでもいいだろ。」って言われそうやね。
>>315
徐々にリークが増えてく場合、仮想メモリ空間なりスワップ領域なり食いつぶして死ぬ。
ていうかオブジェクト開放時にリソースも開放する設計にしとけばリソースも回収できる。
GCは俺も余り好きじゃないが、GCがメモリだけ回収してリソース回収しないって認識は流石に…

**デフォルトの名無しさん** · 2014/09/28(日) 02:56:51.92

>>317
そりゃ、プログラム終了までに開放すれば良いような、ヒープみたいなリソースなら良いけど、ファイルにしろDBにしろ他のプロセスなどと共用するリソースは、必要なくなったら即時開放が必須だろう。

**デフォルトの名無しさん** · 2014/09/28(日) 07:40:32.09

今の時代だとGC搭載のプログラムで動かしまくってるからなぁ
メモリなんてほぼ無限
Cのような言語で組まれたものならfreeしなくても大差ないくらいだよなぁ
でも入れるけど

**デフォルトの名無しさん** · 2014/09/28(日) 08:12:04.95

>>316
ただのバカ乙 w

**デフォルトの名無しさん** · 2014/09/28(日) 10:18:03.79

> ていうかオブジェクト開放時にリソースも開放する設計にしとけばリソースも回収できる。
> GCは俺も余り好きじゃないが、GCがメモリだけ回収してリソース回収しないって認識は流石に…
↑ こいつ最高のバカ
メモリの使用状況をトリガーとするGCでメモリ以外のリソースも管理するとか。死ねゴミクズ。

**デフォルトの名無しさん** · 2014/09/28(日) 11:05:15.19

>>309
win31時代の話をされても

**デフォルトの名無しさん** · 2014/09/28(日) 11:07:23.91

>>321
GC はメモリ回収しかしないと思うよ、OSリソース回収は自分で書かないとね
C# や Java にもデストラクタがあったほうがよかったと思うことがしばしば

**デフォルトの名無しさん** · 2014/09/28(日) 11:08:13.02

メモリリークもゴミみたい思える大きさだから、freeしなくてもいいって？

**デフォルトの名無しさん** · 2014/09/28(日) 11:12:12.60

リークを定義できない人間がfree()不要論を朗誦しているんですよ

**デフォルトの名無しさん** · 2014/09/28(日) 11:52:29.34

keep it simple stupid を誤解釈すると free不要になるのかも知れない

**デフォルトの名無しさん** · 2014/09/28(日) 11:56:57.44

レベル0: 常にfreeを書かない
レベル1: 常にfreeを書く
レベル2: 条件に合わせてfreeを省略すべきときだけ省略する

**デフォルトの名無しさん** · 2014/09/28(日) 13:53:02.44

ま、この場合のkissは「常にfreeする」か「一切freeしない」のどちらかだろうな
ハイブリッドにするのは最適化に近いので、最後の手段としたい

**デフォルトの名無しさん** · 2014/09/28(日) 14:11:49.10

>>328 そんな単純なことすら理解できず教条的に「freeしろ」と叫ぶだけのバカが、
まだこんなに多いとわかった、ってのが収穫だな。

**デフォルトの名無しさん** · 2014/09/28(日) 15:07:03.68

ポリシー君乙 w

**デフォルトの名無しさん** · 2014/09/28(日) 16:34:11.76

>>329
君、free() が不要な例と絶対に必要な例とをコードで示してくれないか？

**デフォルトの名無しさん** · 2014/09/28(日) 17:17:57.68

楽（らく）したいだけの人だから、答えられ...