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/02/16(土) 19:16:41.30

アスペ顔のデブくさお再来か

**デフォルトの名無しさん** · 2013/02/16(土) 19:18:26.84

解放処理で不具合が出たり処理食われるから解放処理は用意しないという論調だけど
この人は全ての解放処理を書かないつもりなのか？
終了直前以外は必要に応じて書くなら結局用意しないといけないと思うんだけど

**デフォルトの名無しさん** · 2013/02/16(土) 20:58:22.35

>>206
別にバグが混入するからって言うのが主目的じゃないよ。
ただ、無駄だから。

なんで無駄だといけないの ?
と問われると、まぁ、無駄な処理を記述するとバグが入る可能性が
増えるし....となる。

無駄なごみを書いたっていいじゃんって言われればそうなんだけど、
他人に強制しないでね。

> この人は全ての解放処理を書かないつもりなのか？

必要な解放処理はもちろん書くし、使うよ。

> 終了直前以外は必要に応じて書くなら結局用意しないといけないと思うんだけど

まず、本質的にプロセスと寿命が等しいオブジェクトというのが存在する。
この場合、オブジェクト（のメモリ）の解放ということは起こりえないので
解放処理を記述することはない。

次に、別に解放処理を書いたからといって使わなければならないということはない。
例えば、イメージデータを保持する領域なんかは、イメージの削除処理などで
解放処理が利用されるが、別にプログラムの終了のときに解放処理を行う必要は
ない。

**デフォルトの名無しさん** · 2013/02/16(土) 21:33:01.38

>>207
だから解放処理が作れるとか作れないとか速いとか遅いとかはこのスレで論ずる事ではないよねという話

**デフォルトの名無しさん** · 2013/02/16(土) 21:37:39.32

何を論じるの？

**デフォルトの名無しさん** · 2013/02/16(土) 22:02:26.79

>>207
> 必要な解放処理はもちろん書くし、使うよ。

これはfree必要派だな。結局free不要と言う奴なんていなかった

なんか、ごちゃごちゃもめてる様に見えたのは前提条件とか
例外的なケースのすり合わせが出来てないだけだったのか

**デフォルトの名無しさん** · 2013/02/16(土) 22:58:23.31

>>204
KKC以来の醜態は自演という事にしてごまかすしかないよなあ。ｗｗｗ

>>210
いかなる場合でもfreeしろという狂信的なfree必須バカがいる。

**デフォルトの名無しさん** · 2013/02/16(土) 23:16:32.58

いかなる場合もfreeしないってのとじゃ話は別なわけだが。

つーか、数学のレベルでいえば、保育園レベルだなｗ　free関数の使い道おしえてくれよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/17(日) 00:12:34.88

> いかなる場合もfreeしないってのとじゃ話は別なわけだが。
そんな事はオレも含めて誰も一回も言っていないぞ。ｗｗｗ
爆笑ログさらされて壊れた? ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/17(日) 00:17:34.29

まあ、free関数の使い道が提示できないだけでおまえの圧倒的敗北が確定なわけだが。

**デフォルトの名無しさん** · 2013/02/17(日) 00:50:36.98

>>187
とっくに出しているが。英語は読めないか。さすがバカ。ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/17(日) 01:04:13.26

バカにされたくさお発狂中age

**デフォルトの名無しさん** · 2013/02/17(日) 01:31:10.56

何度みても笑える。ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/17(日) 03:47:01.93

こいつ誰と戦ってんだ

**デフォルトの名無しさん** · 2013/02/17(日) 09:32:46.14

プログラマーって寂しい奴ばっかなの？

**デフォルトの名無しさん** · 2013/02/17(日) 10:46:00.43

マだけにはなりたくないよね

**デフォルトの名無しさん** · 2013/02/17(日) 12:01:52.97

>>217は特殊な人です。
一般的とは思わないでください。

**デフォルトの名無しさん** · 2013/02/17(日) 12:06:25.96

>>218
QZとだよ

**デフォルトの名無しさん** · 2013/02/17(日) 12:08:00.33

>>218
戦いではない。バカを一方的になぶっているだけだ。ｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/17(日) 14:31:13.77

>>218
他人を納得させられるような議論ができなくて「俺以外全員バカ」モードに入った

**デフォルトの名無しさん** · 2013/02/17(日) 14:32:54.62

>>223
泣いてるのお前一人だぞ

**デフォルトの名無しさん** · 2013/02/17(日) 14:59:06.71

>>224-225
↓こんな醜態さらしてそんなに悔しい? バカなんだからだまってりゃよかったのに。ｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

**デフォルトの名無しさん** · 2013/02/20(水) 21:35:05.54

・・・

**デフォルトの名無しさん** · 2013/02/21(木) 03:43:09.19

おまえはfreeどころかmallocも使うなアホ

**デフォルトの名無しさん** · 2013/03/24(日) 16:40:22.40

実際、最大要素数さえ決めりゃmalloc使わなくても大概のデータ構造は作れるのよね

**デフォルトの名無しさん** · 2013/03/24(日) 16:47:10.01

大概の、じゃなくて、なんでも、だよ。
その代わりユーザーには何の理由もなく受け付けるデータ量の上限、みたいな制限が加えられる。

**デフォルトの名無しさん** · 2013/04/09(火) 12:16:59.06

どこかの関数で巨大なmalloc()をして、もうその関数では必要なくなってもfree()
しないでメモリが足りなくなるとかの危険性は？

もちろんfree()してもメモリが足りなくならないという保証はないけど、少なくとも
free()した領域は再利用される

**デフォルトの名無しさん** · 2013/04/09(火) 12:53:53.95

>>231
このスレは、そういう場合の話ではない

**デフォルトの名無しさん** · 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がまた必要になってないか」って
気にしながらプログラミングするんだろうか。