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/

**デフォルトの名無しさん** · 2014/10/13(月) 16:23:42.16

>>432
答えられないのか。
情けねーな。

**デフォルトの名無しさん** · 2014/10/13(月) 16:29:31.58

他人に答えを強制するくせに>>428には答えずに逃げる、と

**デフォルトの名無しさん** · 2014/10/13(月) 16:33:17.28

>>436
雑用は雑魚にやらせてるから。
システム導入時にユーティリティーが一式ついてきたみたいだよ。

**デフォルトの名無しさん** · 2014/10/13(月) 17:13:00.13

>>432
その判断は大域的にならざるを得ないわけだよな。
個々の処理がいつどのように呼ばれるか、さらにはそれより後で実行される処理で
新たなヒープメモリの確保がされるのか、等々、気にしないとならないわけだ。
なんとも前近代的な印象を受けるが。

**デフォルトの名無しさん** · 2014/10/13(月) 17:36:51.42

>>418
で、32bitのコンパイラで断片化させて2Gの壁に突き当たると
64bitの場合の限界は環境依存なんだっけ？

**デフォルトの名無しさん** · 2014/10/13(月) 17:39:47.21

>>437
まさかの雑魚以下!?

**デフォルトの名無しさん** · 2014/10/13(月) 17:57:02.26

このスレまだあったんだ。

おっさん感激 !!

ところで、Free必須論者は
本質的に寿命がプログラムの寿命と同じオブジェクトが
あるということは認識してくれているのかな。

例えばさっきのcpのハッシュテーブルだったり、
コンパイラの構文木だったり

これらのオブジェクトが必要なくなるとき=プログラムが終了するとき
なんだけど、こんなかんじでfreeして開放された領域が2度と使われないことが
保障されているオブジェクトが存在するということは認識してくれている ?

**デフォルトの名無しさん** · 2014/10/13(月) 18:06:04.38

>>441
> コンパイラの構文木だったり

もうその話耳タコで飽きたわ

**デフォルトの名無しさん** · 2014/10/13(月) 18:11:11.64

>>441
OSと協調できないのはglibcの欠陥だから、主にLinuxでのみ問題になるんだよね。
Linuxなんか使うからそういう事になるんだよ。

まともなランタイム使ってれば解放して大丈夫だよ。
ホントGNU製品って糞だよな。
糞を一般化して語るなって話。

**デフォルトの名無しさん** · 2014/10/13(月) 18:15:57.06

>>297
「私はRAIDの復旧にcpを使うバカです」

ということだろ？

**デフォルトの名無しさん** · 2014/10/13(月) 18:19:35.33

>>434
> 大丈夫、ちゃんとわかってるから
わかってるなら、↓こういう間抜けな発言はしない。ｗｗｗ

> From: [395] デフォルトの名無しさん <>
> Date: 2014/10/13(月) 08:15:56.25 ID:BlK6LuSG
>
> >>297はブログに書くことじゃなくてツイッターにでも書けばいい。
>
> 「私はRAIDの復旧にcpを使うバカです」
>
> 一行で済む。

**441** · 2014/10/13(月) 18:24:11.09

>>442
それなんで、cpのハッシュテーブルっていう実例が出てうれしいです^ ~

自分の経験で出せる例だと、
連立一次方程式を解くときの疎行列なんかぐらいになっちゃいます。

**デフォルトの名無しさん** · 2014/10/13(月) 18:27:48.36

>>445
>>406 の答え書けないなら、でてくんなよ w

**441** · 2014/10/13(月) 18:32:16.15

>>443
オブジェクトの寿命 = プログラム(プロセス)の寿命
なオブジェクトが存在し、それはfreeをしても確保したメモリ領域が
再利用されることはない。
というのはご理解いただいているのですね。

**デフォルトの名無しさん** · 2014/10/13(月) 18:33:33.08

>>446
Linux特有の問題。
いまどきのランタイムはメモリを開放すると即座にOSに返す。
OSは適切に取り扱う。

ところがglibcはOSの機能を使えない。
ディスクに退避されたデータによってスラッシングが引き起こされる。

「だからfreeするべきではない」
↑これ間違い。

欠陥ランタイムを使うべきでないというのが正しい。

**デフォルトの名無しさん** · 2014/10/13(月) 18:36:40.23

>>441
＞ところで、Free必須論者は
＞本質的に寿命がプログラムの寿命と同じオブジェクトが
＞あるということは認識してくれているのかな。

認識してます。
結局のところ C/C++ にしか関係ない些細なことなんです。他の言語はすでにこの手の話は自動化されていますし、うまくいっているとはいいませんが。

**デフォルトの名無しさん** · 2014/10/13(月) 18:38:39.11

>>448
俺は、きちんとモジュール化するべきだと思うよ。
ハッシュテーブルを実装するなら、テーブルを削除する時点でメモリーも
解放する。
そして、他のプログラムでもそのハッシュテーブル実装を使えるようにする。

メモリーの開放が遅いのはglibcの欠陥。
欠陥品に合わせてすべてを台無しにする必要はない。
欠陥品を使わないことが大切。

まあ、こんな当たり前のことがわからないから雑魚なんですわ。

**デフォルトの名無しさん** · 2014/10/13(月) 18:39:27.83

>>449
＞いまどきのランタイムはメモリを開放すると即座にOSに返す。
ほう、それは初耳、いったん握ったメモリは返さないものとおもっていた‥

**デフォルトの名無しさん** · 2014/10/13(月) 18:46:38.76

>>452

**デフォルトの名無しさん** · 2014/10/13(月) 18:46:52.49

>>448
そういうケースが存在することはわかってるが、わざわざそんなケースだけを特別扱いすべきとは思わない
測定してみて、本当に解放が問題になる場合に free をやめると言うならわかる
つまり、小手先の最適化と同じレベルの話

**デフォルトの名無しさん** · 2014/10/13(月) 18:52:40.24

プログラムの再利用性、安全性を真剣に考えると、RAIIは有効な手法。

これに反対するのは雑魚。

Linuxを使わないことも大事。
Linuxはファイルのコピーすら満足にできないって>>297が述べてる。

**デフォルトの名無しさん** · 2014/10/13(月) 18:59:10.36

>>297のケースで有効な解法はメモリプール
これがわからない奴は雑魚

**デフォルトの名無しさん** · 2014/10/13(月) 19:06:21.99

>>449
cpはハッシュテーブルを最後まで使うから
即座にOSにメモリを返すとか、何にも関係無いんだよなぁ…

**デフォルトの名無しさん** · 2014/10/13(月) 19:15:48.89

>>457
メモリープールが問題になってるのに、メモリープールが解法と言ってるのだから、
わからなくて当然。
もう少し勉強しなさい。

**448** · 2014/10/13(月) 19:19:27.66

>>454
認識が確認できて幸いです。

わざわざそんなケースと言われるけど、
このようなケースは結構多いと思うんですよ。

普段使ってるgccもたぶんそうだし、
cpだってそう。

本質的に記憶領域の再利用がされないfreeをするために
循環参照があるリンクトリストを再帰で開放してまわったり
freeをするための1万回のループをわざわざ書くというのは
なんというか、知的ではないのではないかと

もちろん、ライブラリ化するために、解放処理を記述するのは
必要ですけど、例えばgccの構文木を保持するコードは
gcc以外に使えるとは思えないなぁ。
だから、専用に作ったんでしょ

**デフォルトの名無しさん** · 2014/10/13(月) 19:24:40.28

変な論法だね‥
「free()/delete してもしなくても状況に大きな変化はない。∴free()/delete しなくてよい。」
と理解していいのかな？

**デフォルトの名無しさん** · 2014/10/13(月) 19:27:50.10

>>459
Linux界隈だとそれでいいんですけどね。
ctagsでインテリセンスより強いとか言ってればいい。

でも、いまどきの人は構文上の誤りは即座に指摘してほしいし、書く端から
補完が効いてほしいですよね。
すると、コンパイラの機能だと思われていたものすらエディタに組み込まれたりするわけですよ。

まあ、Linuxなんか使ってると20年前で時が止まっちゃうんですけどね。
世間ではそういうのを雑魚って言うんです。

**デフォルトの名無しさん** · 2014/10/13(月) 19:32:32.92

>>456
その解法がメモリープールというのは、
ハッシュテーブルの領域全体をmallocでとって来て
中身を自前のメモリ管理コードで管理して、
解放するときは全体をfree一発で解放ってことでしょうか ?

malloc-freeはsbrkやmmapで確保した領域を
管理するメモリプールだと考えられます。

ですので、再利用する見込みのない領域をわざわざfreeする必要は
ないんじゃないのって考え方は、
上記の大きな記憶領域を確保して、解放はfree一発というものと
同一になります。

**デフォルトの名無しさん** · 2014/10/13(月) 19:36:18.84

>>461
全然関係ないこと書いてないで、

> 循環参照があるリンクトリストを再帰で開放してまわったり
> freeをするための1万回のループをわざわざ書くというのは

についてコメントしたら？

**デフォルトの名無しさん** · 2014/10/13(月) 19:39:14.34

>>462
それは>>363で指摘したから、そういう話じゃないと思う。

GNUマンセーって話でしょ。

**デフォルトの名無しさん** · 2014/10/13(月) 19:40:18.64

>>463
関係ないと思うなら、もう少し勉強しましょう。

**デフォルトの名無しさん** · 2014/10/13(月) 19:43:33.90

>>459
> このようなケースは結構多いと思うんですよ。

自分が作るソフトもそうなの？

まあ、そうだとしても構文木を作成してる所以外でリークしない自信があるとか、リークしても気にしないと言うなら止めないよので、自由にやってくださいな。

**デフォルトの名無しさん** · 2014/10/13(月) 19:44:39.36

>本質的に記憶領域の再利用がされないfreeをするために
>循環参照があるリンクトリストを再帰で開放してまわったり
>freeをするための1万回のループをわざわざ書くというのは
>なんというか、知的ではないのではないかと

リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
同じだと思うんだが、それを「わざわざ」と言うのはどういうスタイルで
書いてんのか気になるな。
循環参照とか言っているところを見ると、fjのときも出てきたような
「作った本人が正しく破棄することができないデータ構造」とかかねぇ。

**デフォルトの名無しさん** · 2014/10/13(月) 19:47:00.34

RAIIはおろかな考えというネタでもう一スレ作れそうな気がするな。

**デフォルトの名無しさん** · 2014/10/13(月) 20:12:51.45

>>467
> リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
> 同じだと思うんだが、

パフォーマンス的には全然同じじゃないよ
コードの字面的に呼び出しが無かったら処理が存在しないとでも思ってるの？馬鹿？

**デフォルトの名無しさん** · 2014/10/13(月) 20:25:00.67

ちなみに>>469は俺です。

あと500レスみんなで頑張ってください。

**デフォルトの名無しさん** · 2014/10/13(月) 20:36:14.64

リンクドリストの場合はmallocすら何回もするのがめんどくさいので、
ブロックで確保して破棄はブロックの数分だけでいいのでは？
ゲームでは常識。

**458** · 2014/10/13(月) 20:39:23.78

>>467
わかりにくい書き方ですみません。

前半の部分は
http://www.slideshare.net/iwiwi/ss-11008471
の3ページの交通ネットワークを表すために
31ページみたいなグラフを作って、その解放コードを
ちまちま、解放することを考えています。

後半は、行列なんかを使った後に
for(i = 0; i < ROW_MAX; i++) {
free(row[i]);
}
free(row);
exit(0);
なんてことをやることを想定しています。

**デフォルトの名無しさん** · 2014/10/13(月) 20:42:43.81

行列は幅が変わらないので、W*Hで確保してW*y+xすれば何度も確保する必要ない。

**デフォルトの名無しさん** · 2014/10/13(月) 20:51:37.45

>>447
わからないから、教えて下さいだろ。池沼。

**デフォルトの名無しさん** · 2014/10/13(月) 21:03:25.09

>>474

>>411
>>434
>>435

**デフォルトの名無しさん** · 2014/10/13(月) 21:09:11.84

>>469
> パフォーマンス的には全然同じじゃないよ

で、そのパフォーマンスが問題になってるの？

**デフォルトの名無しさん** · 2014/10/13(月) 21:09:16.45

>>472
前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
いざ壊そうと思ったときに嵌ったりバグったりする典型だね。
後者は、使い捨てのやっつけプログラムとかじゃなければ普通こんなコードが
exit()の直前に置かれることはないと思うし、そうであれば普通に破棄処理として
書くと思うんだけどなぁ。それを「わざわざ」と思うのはまぁ、個人の感覚かも知れんが。
＃あぁ、rowもグローバル変数だったりするのかね？

**デフォルトの名無しさん** · 2014/10/13(月) 21:23:47.22

>>476
問題になってるかどうかはどうでもよくね？

1ナノ秒でも1ミリ秒でも速いほうがいいだろう？
速くなることにメリットはあれどデメリットはない。

**デフォルトの名無しさん** · 2014/10/13(月) 21:31:35.61

>>478
小手先の最適化をバンバンやれと言う主張ですね
まあ、頑張ってくださいな w

**デフォルトの名無しさん** · 2014/10/13(月) 21:47:30.33

>>479
ちりも積もれば山となるってことわざ知らないの？

1ナノ秒でも積もれば1時間になるんだけど。

**472** · 2014/10/13(月) 21:54:16.26

>>477
> 前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
> いざ壊そうと思ったときに嵌ったりバグったりする典型だね。

ですので、freeせずにOSの持つメモリ管理機構を利用して
exitですね。
freeするためにプログラムを作っているのではなく
データを扱うためにプログラムを作っているのですから。

メモリリークチェッカを使わなければならないとかで、絶対freeしろって
言われたらmyMallocとmyFreeを作って、全体をmallocして最後に
一発freeってやりたいです。

> 後者は、使い捨てのやっつけプログラムとかじゃなければ普通こんなコードが
> exit()の直前に置かれることはないと思うし、そうであれば普通に破棄処理として
> 書くと思うんだけどなぁ。それを「わざわざ」と思うのはまぁ、個人の感覚かも知れんが。

なにをもってやっつけのプログラムと言うかはさており、
cpは実際にexitの前にforgetAllって終了処理が

word2vec
http://word2vec.googlecode.com/svn/trunk/word2vec.c
ではvocab, vocab_hash, expTableは解放するならmainからのreturn
直前に記述することになりますね。

> ＃あぁ、rowもグローバル変数だったりするのかね？

あくまで、例のための例ですが、グローバルなときもあります。
# というか、そのほうがすっきりする。

**デフォルトの名無しさん** · 2014/10/13(月) 21:57:14.67

>>480
> ちりも積もれば山となるってことわざ知らないの？

知ってる。
だから、小手先の最適化なんてしないんだよ。
速さより、重要なことってあるんだよ。

**デフォルトの名無しさん** · 2014/10/13(月) 22:05:33.55

速さよりも重要な事なんて無いよ。
金さえあればスパコンがほしいぐらい。

**デフォルトの名無しさん** · 2014/10/13(月) 22:09:28.23

そーゆーレベルだとアルゴリズム工夫した方が早くならね？

**デフォルトの名無しさん** · 2014/10/13(月) 22:15:14.16

>>483
それは、正確さだなｗ
あと脆弱性への強さ。
コードの見通しのよさ、コードの柔軟さ。

速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？

**デフォルトの名無しさん** · 2014/10/13(月) 22:17:23.60

>>483
マルチスレッド使っての高速化とかは無理？

**デフォルトの名無しさん** · 2014/10/13(月) 23:38:21.18

>>483 は素早く間違った結果が欲しいんだろう w

**デフォルトの名無しさん** · 2014/10/13(月) 23:41:05.25

>>470
いや、俺はお前みたいな馬鹿じゃないぞ

**デフォルトの名無しさん** · 2014/10/13(月) 23:41:20.11

>>485
> 速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？

そういう分野は、速さと言うよりどんな場合でも決められた時間に間に合うこと（つまり、遅くならないこと）を要求される
ハードリアルアイムでググってみそ

**デフォルトの名無しさん** · 2014/10/13(月) 23:42:12.91

freeが必要だと思う人はしていただき、その必要性はないと思う人はしない
ということで各々ご対応をお願い致します。

それでは、ここらでお開きとさせていただきます。

皆様、活発な意見交換、誠にお疲れ様でございました。

**デフォルトの名無しさん** · 2014/10/13(月) 23:50:17.84

>>490
>>379

**デフォルトの名無しさん** · 2014/10/14(火) 00:04:57.97

>>491
おまえ、まだいたのかｗｗｗｗ

**デフォルトの名無しさん** · 2014/10/14(火) 00:16:00.24

>>492
チキン君乙

**デフォルトの名無しさん** · 2014/10/14(火) 00:17:04.09

よく吠えるやつほど弱いのはどこでも同じだな

**デフォルトの名無しさん** · 2014/10/14(火) 01:48:42.60

>>475
わからないから、教えて下さいだろ。池沼。

**デフォルトの名無しさん** · 2014/10/14(火) 06:32:50.32

>>403
ネタ主張を1400レスも続けるとかヒッデェなぁ…

**デフォルトの名無しさん** · 2014/10/14(火) 06:34:31.53

>>494
うんうん、そうだねー
で、説明は？ w

**デフォルトの名無しさん** · 2014/10/14(火) 07:21:14.97

この問題の根は、ファイル名に日本語を使うべきでないや、メールタイトルに
日本語を使うべきでない、と同じです。

こういった問題について議論すると、必ず日本語を使うべきでないという結論に落ち着く。
しかし、本当の答えは、日本語が使えるべきです。

RAIIは多くの問題を論理的に解消できるので、常に使えるようにするべきです。

LinuxでRAIIが問題を引き起こすことは良く知られています。
メモリーの開放に時間がかかるので、メモリーの明示的開放を避けるべきという議論も
その一つです。
しかし、本当の答えは、Linuxでもメモリーの開放に時間がかからないようにすることです。
RAIIを避けるべきという議論は、過去に繰り返された日本語を使うべきでないという議論と同じです。

**デフォルトの名無しさん** · 2014/10/14(火) 08:43:00.85

Linux以外なら、細かく何度もmallocして、しかもスワップアウトした領域を
freeして回っても遅く無いってか？馬鹿じゃないの？

**デフォルトの名無しさん** · 2014/10/14(火) 08:49:08.26

先に大きめの領域確保して、開放すれば
細かく領域するときの速度が上げれるかもね
なんででしょうね？

**デフォルトの名無しさん** · 2014/10/14(火) 08:50:02.00

☓細かく領域するとき
○細かく領域確保するとき

**デフォルトの名無しさん** · 2014/10/14(火) 09:05:57.25

>>499
その問題の原因は、確保したメモリー領域の先頭に大きさなどの情報を持たせることです。
どれだけの大きさを開放するか調べるために遅い二次記憶から情報を復元します。

ですから、仮想記憶が一般的になると、多くのランタイムライブラリがメモリー管理を
OSに任せるようになりました。
メモリーの開放が直接OSによって処理されることで、OSは二次記憶から情報を取り出さずに
解放するタイミングを得ます。

残念ながらLinuxではそうなっていないため、メモリーを開放すると遅いので
解放するべきではないと主張する人が現れるようになりました。

**デフォルトの名無しさん** · 2014/10/14(火) 09:58:22.05

exitする直前にfreeしないのは、OSのメモリ管理機能を利用してるってことなんだけど？

**デフォルトの名無しさん** · 2014/10/14(火) 10:05:00.55

てなしたやはたてやな

**デフォルトの名無しさん** · 2014/10/14(火) 10:21:21.80

長文の割にワケワカなこと書いて漫画な

**デフォルトの名無しさん** · 2014/10/15(水) 20:16:19.78

>>503
バカ発見。

**デフォルトの名無しさん** · 2014/10/15(水) 20:25:23.13

自己紹介乙

**デフォルトの名無しさん** · 2014/10/16(木) 04:07:06.14

>>502
＞ですから、仮想記憶が一般的になると、多くのランタイムライブラリがメモリー管理を
＞OSに任せるようになりました。
＞メモリーの開放が直接OSによって処理されることで、OSは二次記憶から情報を取り出さずに
＞解放するタイミングを得ます。
そんな非効率的なことをやってる環境があるの？

**デフォルトの名無しさん** · 2014/10/16(木) 06:57:35.08

VCのmallocはHeapAllocに丸投げする場合があるようだが、一般的かっていうと…

**デフォルトの名無しさん** · 2014/10/17(金) 09:39:29.66

何を非効率と言いたいか知らないが、アプリがfreeしまくればメモリアクセスは当然発生する。

サクッと終了しちゃえば、OSはそのアプリに割り当ててたページをそのまま割り当て解除して
回収するだけ。

この効率の差を理解できないか、OSというものを理解してない発言でしかないわけだがwwwww

**デフォルトの名無しさん** · 2014/10/17(金) 16:14:49.18

>>510
で、その効率の差が実感できるアプリケーションってなに？
心のよりどころの cp だけ？ w

**デフォルトの名無しさん** · 2014/10/17(金) 16:21:12.12

アプリ終了以外では
ある程度の大きさ以外は、freeしても割り当て解除はされませんよ
だから、ヘタすると、メモリ分断が怒って....

**デフォルトの名無しさん** · 2014/10/17(金) 17:45:37.94

>>511 メモリを大量に確保するアプリならどれにでもあてはまる、
ということすら理解できないのかw

**デフォルトの名無しさん** · 2014/10/17(金) 18:16:31.32

>>513
> >>511 メモリを大量に確保するアプリならどれにでもあてはまる、

メモリの確保の仕方によって全然違うことも理解できないアホ乙

**デフォルトの名無しさん** · 2014/10/17(金) 18:16:40.65

>>510
>>502の言うようにOSにメモリ確保を丸投げしてる場合、APIによってはOSも参照カウントの操作・確認も行うかもしれんぞ？
(例えば、WinのCreateFileMappingで確保したページファイル領域は生きたハンドル(を持つプロセス)があれば残る)
解放をOSに任せることで確実に軽減できるのは、アプリ側が解放すべきハンドルやポインタを走査するコストだけ。
その他のコストは実装依存でどのくらい軽減できるかが異なる。
…けど、これが問題になるケースも実装もそう多くないだろうからなぁ…

>>513
メモリ管理情報の操作に時間がかかってるんだから、小さい領域を山のように確保してるアプリじゃないか？
ポインタの走査にも時間がかかりやすい構造(馬鹿正直なリンクリストなど)だとよりコストが増える。

**デフォルトの名無しさん** · 2014/10/17(金) 19:39:54.06

HeapAllocはプロセス内で確保したメモリを小分けして管理してるだけで、
それをOSの機能の一部みたいに扱うのはなんかモニョるな。

**デフォルトの名無しさん** · 2014/10/17(金) 20:22:20.74

>>511
お前がひねり出したうんこプログラム全部

**デフォルトの名無しさん** · 2014/10/17(金) 21:53:10.77

>>516
言いたいことは分かるがWin32APIって案外そういうの多いからなぁ…
user32とかkernel32にも標準CライブラリみたいなAPI(sprintfモドキも居るしｗ)が結構一杯ある。
MulDivやCopyMemoryみたいなのも居るし、CopyRectに至ってはただの32バイトコピー。
HeapAlloc程度でモニョってたらこいつらはモニョるなんてレベルじゃすまんぞｗ
MulDiv(32ビット値3つから中間値64ビットの掛け算と割り算)が何故カーネル扱いなのかと。

**デフォルトの名無しさん** · 2014/10/18(土) 01:39:31.35

>>510
つスレッドタイトル

**デフォルトの名無しさん** · 2014/10/18(土) 13:08:53.33

>>510
昔はそんなにメモリが潤沢になかったから、アプリが終了する前でも
不要になったら開放する方が、いろいろとよかった時代もあったんだよ

>>all
もうお前ら不毛だからこの辺にしとけ

**デフォルトの名無しさん** · 2014/10/18(土) 13:50:57.61

>>520
そうもいかない、そんな結論では C++ がいまだに営々と複雑化にこだわっている立つ瀬がない‥

**デフォルトの名無しさん** · 2014/10/18(土) 16:59:54.98

メモリは動的に確保するくせに開放は静的にOSに任せたい
だったら、必要になるであろうメモリも配列で静的に確保しとけばいいんじゃね？
とか思うんだが…

でこういうこと言うと荒れるから、結論は
freeしたい人はして、したくない人はしない
で終了でいいんじゃね？っていう

**デフォルトの名無しさん** · 2014/10/18(土) 17:06:19.18

>>522
それは古来lispでもよくみられたプール式、cons セルという定サイズ領域を多量に使う用途で採用されているのをみたことがある

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

解放しないプロセスってデバッガで実行すると終了時に大量のleak検出を吐き出したりしないのか？

**デフォルトの名無しさん** · 2014/10/20(月) 02:00:02.18

吐いたとしても意図的に吐かせてるつもりだろうから問題ないんだろ

**デフォルトの名無しさん** · 2014/10/20(月) 12:45:42.29

たぶんメモリリークしてもプロセス終了時に
全部解放されるんだから大丈夫だと思ってるんじゃない？

**デフォルトの名無しさん** · 2014/10/20(月) 12:49:49.79

リソースリークとメモリリークの区別もできないとかが典型例だな

**デフォルトの名無しさん** · 2014/10/20(月) 19:41:25.28

リークと解放の区別が付かないバカは死ねば良いと思う。

**デフォルトの名無しさん** · 2014/10/20(月) 19:48:59.73

メモリリーク検出ツールでリークと解放の
区別がつかなくなるから解放しとけって話でしょｗ

**デフォルトの名無しさん** · 2014/10/20(月) 23:06:26.87

プログラム中で確保したメモリの各々がfreeする必要あるかないか、間違えずに
判断できる達人ならリークチェッカ使う必要ないな。

**デフォルトの名無しさん** · 2014/10/21(火) 12:31:58.89

>>530を省略すると、

ミスをしない人はリークチェッカはいらない。

ということ。

**デフォルトの名無しさん** · 2014/10/21(火) 12:58:58.48

要約？

**デフォルトの名無しさん** · 2014/10/21(火) 13:01:27.03

普通にできないといけないことではないかと

**デフォルトの名無しさん** · 2014/10/21(火) 13:25:02.74

リークチェッカなんて必要ない。
作った奴は馬鹿だ。
ミスをしなければいいだけの話。