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/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

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

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

ミスしてもいいのでは、修正できれば
いきなり完成品？作れる人いるのけ

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

デバッグモードでコンパイルしたときだけ解放したら
良いだけじゃん馬鹿すぎ

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

>>535
その修正をサポートするルールがリークチェッカでしょ？

で、free不要なんていって、free書いてないから
たくさん出るエラーの中から本当にリークしているものを
探して出すというマヌケな作業を行うｗｗｗ

結論出たじゃん？ freeは必要。

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

便利な道具がある。
とかいうとわからないでも出来ると勘違い...

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

なんでfree関数というものがあるのかを考えればわかるよな
もう終わりだろ…

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

意図的にfree省略してる場合は>>536で済むってのは置いといても、
>>534ではリークチェッカ自体が不要と言っているのに、
>>537ではリークチェッカの為にfreeが必要って変な結論だなぁ…

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

リークチェッカのエラーをなくすことが答えだと思ってる人もいますね
微妙な...

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

リークチェッカーでリークを葬ったら、おもむろに選別していけば言いだけの話
というか、リソースリークの方が深刻でちょっと困っている

**デフォルトの名無しさん** · 2014/10/22(水) 21:25:19.20

おもむろに選別する効果・・・0.001秒速くなる。
デメリット、選別作業に数時間。
ドラブルあって、戻すのに数時間

**デフォルトの名無しさん** · 2014/10/23(木) 01:07:59.70

>>542
リソースの確保・開放処理をリークチェッカと同じ仕組でラップしよう。

**デフォルトの名無しさん** · 2014/10/23(木) 08:36:30.18

>>544
api の数だけラップを用意するのもなんだかね‥

**デフォルトの名無しさん** · 2014/12/03(水) 21:28:00.02

C++だと、動的確保って

int *a = new int;

/*
aを使った処理
*/

delete a;

みたく書くと思うけど、deleteしないとアプリケーションを終了させても
確保されっぱなしだよね？
free()不要とか言ってるやつは、上記でいうdelete不要って言ってるのと
同じだよね？

**デフォルトの名無しさん** · 2014/12/03(水) 21:41:48.53

newは互換性のためにmallocで実装されてると聞いたことがある。ほんとか知らんけど。

**デフォルトの名無しさん** · 2014/12/03(水) 22:01:51.69

>>546
＞deleteしないとアプリケーションを終了させても確保されっぱなしだよね？
いや、それはない。アプリ終了時にアプリの使用していたメモリは OS が解放する。これは基本的な共通認識。
それをみこして free()/delete を①まったくしないでもいい、②選別して使用しないのもありだ、③信者ならどんな new/malloc() も必ず delete/free() すべきだ、真っ向に対立している。

**デフォルトの名無しさん** · 2014/12/03(水) 22:25:43.16

③選別するほうが面倒くさいだろう

**デフォルトの名無しさん** · 2014/12/04(木) 02:18:35.19

C++なら、メモリマネージメントクラス書くでしょ。その前にstd::vectorあるけど。

**デフォルトの名無しさん** · 2014/12/04(木) 04:20:29.25

Jane使ってる人は分かると思うけど、一度に多量の画像を保存する機会が多いと思う
そしてJaneは一度立ち上げたらOS再起動するまで大抵立ち上げっぱなし

そんな状態で画像の展開領域のためにmalloc()もしくはnewしたメモリをfree()やdelete
しなかったらどうなる？これ32bitアプリでしょ？120～150枚ほど画像を開くと、例えば俺の
環境の場合Windows8.1だからJaneには2GB割り当あられるけど、free()しないとすぐに
メモリがなくなっちゃうね

**デフォルトの名無しさん** · 2014/12/04(木) 07:46:58.88

delete/free()不要って言ってる人って、もはやなぜメモリを動的に確保するのか？
の意味を見失ってる人ですよね？
可哀想です

**デフォルトの名無しさん** · 2014/12/04(木) 08:53:33.85

>>548
最初は1を主張する馬鹿を論破するだけで、2と3の区別なんて無かったんだけどなぁ…
2に対する3を定義しなおして信者信者言うのは論破された1が苦し紛れに言い出したかのような話題でなんていうかアレ。

そもそも2は全てdelete/freeも出来ない奴のスキルでは不可能だし、
メンテナンス性などの面から見ても必要があれば全て開放できる設計でないとダメ。
そもそも選択して開放しない方が良いなんて言うケースの方が例外的なのに、そんなの持ちだしてまで騒ぐなよ、と。

>>552
だよね。本来はその一言で終わる話題なのに・・・

**デフォルトの名無しさん** · 2014/12/04(木) 09:15:31.23

ガベージコレクションはいらない、と必死でやせ我慢してC++を使う俺カッコイイ、というわけですねわかります
本来はこの一言で終わる話なのに、可哀想です

**デフォルトの名無しさん** · 2014/12/04(木) 12:56:10.33

>>554
> 必死でやせ我慢して

すまぽも知らない老害乙

**デフォルトの名無しさん** · 2014/12/04(木) 18:22:41.52

なまぽおいしいです

**デフォルトの名無しさん** · 2014/12/04(木) 20:36:19.32

>>554
GC はまだ「完成された」というほどの領域に至っていない、Mark&Sweep とか　CopyGC, 世代別GC、incrementalGCなど、いろんな手法を駆使してだましだまし実装しているレベル
うそだと思うのなら、スマフォアプリを見ればよい、スマフォは定期的に再起動しないといけないレベル、iphone は定期的にiOSアップデートの方が先にやってくるようだが

**デフォルトの名無しさん** · 2014/12/04(木) 20:49:21.59

malloc/freeを確実に行う方法は完成している、とでも言うのかwwwwwwwwwww

**デフォルトの名無しさん** · 2014/12/04(木) 20:50:13.03

研究が盛んなあらゆる分野に「まだ「完成された」というほどの領域に至っていない」って
喧嘩売ってみろよw

**デフォルトの名無しさん** · 2014/12/04(木) 21:03:43.58

>>558
簡単なラッパをかませばいいだけの話、それすらもできないの？

**デフォルトの名無しさん** · 2014/12/04(木) 21:25:34.66

いろんな手法を駆使してだましだまし漏れがないようにしているレベル、って言うんじゃないのか、それw

**デフォルトの名無しさん** · 2014/12/04(木) 22:34:16.24

それって言語レベルで完全なGC無いと満足できませんっていってないか？

**デフォルトの名無しさん** · 2014/12/04(木) 23:15:24.98

malloc/freeでバグばっかり出してる奴が「freeしない」という解決策を正当化しようとしているだけの話。

**デフォルトの名無しさん** · 2014/12/05(金) 00:48:52.11

この感じだとバグ出す以前の問題で、deleteの使い方知らずに恥かいたJava厨なんじゃね？

**デフォルトの名無しさん** · 2014/12/05(金) 01:39:25.94

なぜメモリを動的に確保する必要があるのか？という基本に立ち返って考えれば
不要論は論外であることに気づくだろう
注：このスレタイからわかるように近年のGCは範疇に入っていない

**デフォルトの名無しさん** · 2014/12/05(金) 08:03:02.81

もともと GC の話じゃないし

**デフォルトの名無しさん** · 2014/12/05(金) 08:19:12.35

>>561
ラッパ一つを「いろんな」「駆使して」とかいうお子様レベルなの？
あと GC はまだまだだよ、Java の業務アプリを60日間起動しているとメモリ占有量が増えてきてきびきび動かなくなるとか勘弁してほしい、スマフォもイマイチだなあ

**デフォルトの名無しさん** · 2014/12/05(金) 11:53:33.63

ほら出た、「俺様のやってる業務には」というすごく狭い世界が、世界の全てだ、みたいな人w

**デフォルトの名無しさん** · 2014/12/05(金) 20:02:26.00

>>559
確かにFORTRAN, COBOL と並ぶ由緒正しき Lisp 様由来の GC に喧嘩を売るのはちょっと怖いが、実はすでに試みてみた‥
http://peace.2ch.net/test/read.cgi/tech/1408017352/201

**デフォルトの名無しさん** · 2014/12/06(土) 00:13:17.80

Qzって、Lisp Schemeでケンカ吹っかけてガン無視されてるよな。

**デフォルトの名無しさん** · 2014/12/06(土) 00:28:28.87

「胸を借りるつもりで」

**デフォルトの名無しさん** · 2014/12/06(土) 01:08:13.40

>>547
演算子 new をオーバーロードするとき、中身は malloc() で書かざるを得ない気がする‥

**デフォルトの名無しさん** · 2014/12/06(土) 03:30:36.01

>>572
VirtualAllocとかOS依存のメソッド使ったり、グローバルな配列を細切れに使ったりも出来るんじゃない？
標準のAPIで書くならmallocしかないけど…
コンパイラ環境側が提供するnewを標準Cの範囲のみで書かなきゃダメな規則とか有るんだろうか？
だけどstd::threadとか標準Cにはどうやっても落とし込めないよなぁ…

**デフォルトの名無しさん** · 2014/12/06(土) 09:58:48.26

いやいや、freeが邪魔になるのは数少ない例外って
世界でものすごく広く使われているプログラムcpがfreeが邪魔だから
最後のfreeしなくなったでしょ

Google word2vecだって最後のfreeは省略している。

上で書いてあるJaneの例はfreeすべき例、
オブジェクトの寿命が終わったのだから。

free絶対主義者の考え方の何が、気に食わないかって
オブジェクトの寿命を意識してプログラムを組んでいないんじゃ
ないかってこと。

リークチェッカに引っかからなければプログラムの実行中
不必要なオブジェクトの領域が確保されていても気にしなさそう。

**デフォルトの名無しさん** · 2014/12/06(土) 11:47:15.03

なぜメモリを静的にではなく動的に確保するのか？の本来の目的を考えれば
自ずと答えは出る

**デフォルトの名無しさん** · 2014/12/06(土) 12:31:58.16

オブジェクトの寿命を意識するってのは、プログラム開始してから終了するまでの
どの期間存在するかを常に意識しろということなのかね。
プログラムの構造化によって生存区間を限定し、不要になった時点で破棄することで
大域的な知識によらずに安全に使用リソースの最小化を図るという考え方が理解できない
原始時代の人なんだろうか。
そういう人は少なくとも関数内でmalloc/freeを使うべきじゃないな。

**デフォルトの名無しさん** · 2014/12/06(土) 12:50:41.02

大域的な知識を基に最適化するのはむしろ今のトレンドだけど

オブジェクトの生存期間を意識し、場合によってはfreeしないことで
プログラムの性能を向上させる話でしょ？
cpやword2vecの例は

**デフォルトの名無しさん** · 2014/12/06(土) 14:49:24.53

自動化ないしは意識せずにできるようにするのはな。
プログラマ自身がしこしこやるのがいったいどこのトレンドだよw

**デフォルトの名無しさん** · 2014/12/06(土) 15:42:19.80

そういうやつは、スレチだがgcつかっとけよもう

**デフォルトの名無しさん** · 2014/12/06(土) 18:25:26.31

cpやword2vecを書くようなプログラマと
その辺で業務システム書いてるドカタを
同じ土俵で論じるのが間違い

**574** · 2014/12/06(土) 19:13:16.22

>>576

>> 不要になった時点で破棄

まさしくそれ、
不要になったと判明した時点で速やかに破棄というのが大前提。

free絶対派はその意識が乏しいんじゃないかと。
なんとなくmallocとfreeは対でなければいけないから漫然と
freeしているだけなんじゃないかと。

上記のJaneの例なら
画像を破棄したらその画像で使用した領域はその時点でfree
スレッドを破棄したら、それに使った領域はその時点でfree

word2vecは入力した文書の統計情報は最後まで利用する
--> 破棄されることがないので、freeする必要がない

**デフォルトの名無しさん** · 2014/12/06(土) 19:41:46.07

それ「最後まで利用」じゃなくて、利用終了時点の判断をネグってるだけ。

**デフォルトの名無しさん** · 2014/12/06(土) 19:46:54.04

プロセスが確保したメモリは、プロセスを終了させても解放されず、
解放するにはコンピュータの再起動が必要となるOSが昔あったなあ。
バグではなく、OSの正規の仕様として。OSの名前忘れたけど。

そんな仕様じゃメモリをいくら積んでも足りないし、連続稼動できないじゃん！

・・・という各方面からの否定的な評価に対し、そのOSの設計者は
「メモリを十分に積まないのが問題」「定期的にリブートすればいいこと」
「メモリ資源の再利用をOSに任せようとするアプリケーション開発者の手抜き」
のようにOS側の問題ではないと一蹴してて、その主張に一理あるということで、
当時はちょっと衝撃を受けたわ。

malloc したものを free することには合理性があるけど。
その価値観に対抗するようなOS設計哲学も存在するということで。
何が正しいのか、唯一の結論を出すのは、なかなか難しいかもねえ（＾o＾）ﾉ

**デフォルトの名無しさん** · 2014/12/06(土) 20:01:10.98

UnixのSIGKILLみたいに問答無用でプロセスが殺されたりせずに、後始末の作業が
できることがシステム全体として保証されてるなら通る理屈だけど、どうせそのような
仕掛けがあるわけじゃないだろうなw

**デフォルトの名無しさん** · 2014/12/06(土) 22:06:14.90

>>581
だからさぁ・・・それをfree不要とは言わないでしょ。
freeしない領域も実質プログラムの終了でfreeを代用してるだけだし、
プログラマの意図としてはfreeすべき場所を把握できているケース。
このスレはfreeも満足に使えないくせにfree不要とか言っちゃう馬鹿を断罪するスレなんだよ。

なんでそこまでして「free不要論は間違い」をfree必須教みたいに扱って敵視してんの？
発端のfree不要とか言っちゃった馬鹿が知恵つけながら粘ってるようでヤなんだけど。

>>584
そこまで行くとkillするAPIも無いとかkillする側が責任持つべきとかになるんじゃね。

**デフォルトの名無しさん** · 2014/12/06(土) 22:10:57.01

プログラムの最初から最後まで領域を優先するようなメモリはStatic使うべし。
MallocはFreeされるべき。

**デフォルトの名無しさん** · 2014/12/06(土) 22:51:56.38

途中でfreeしてメモリを効率よく使えるようmallocするんじゃないんかと…

**デフォルトの名無しさん** · 2014/12/06(土) 23:09:29.33

Malloc自体は遅いんだよ。
Freeしなかったら蓄積してって確保できなくなるぞ。
まぁ、最近のコンピュータで困るかはわからん。

**デフォルトの名無しさん** · 2014/12/06(土) 23:29:03.74

GCを前提としたmallocだと、極端な奴ではポインタずらして管理情報をちょこっと書くだけ、
って場合もあるけどなw

**デフォルトの名無しさん** · 2014/12/06(土) 23:32:11.16

なにそのオレオレライブラリ。

**デフォルトの名無しさん** · 2014/12/07(日) 00:10:44.64

mallocしたメモリをGCしてくれるわけねーだろｗ

そういうやつはC++ならせめてgcnewくらい使え

**デフォルトの名無しさん** · 2014/12/07(日) 05:38:55.41

これが fopen() / fclose()、低水準なら open()/close() の話だったりすると、
プロセス終了時にオープンされているものは OS がクローズしてくれるものにもかかわらず、
「プログラム終了時の fclose() を省略しないやつは糞」というのはあまりきかないね…
ま 10万20万と fopen() するわけではないからね…

**デフォルトの名無しさん** · 2014/12/07(日) 09:22:07.16

つーか、終了時のメモリ開放処理程度をめんどくさいとか言うやつは
もうプログラマなんか向いてねーからやめちまえよ

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

>>593
プログラマがめんどくさいだけならいいけど、
ユーザーが遅さを体感することになるからな
ユーザビリティの観点からもプロセス終了時の明示的メモリ解放はやめるべきだ

**デフォルトの名無しさん** · 2014/12/07(日) 09:50:23.92

>>592
「俺はmallocとfreeを使える」って所で学習が止まってしまっていて、そこまで到達したことだけが
心の支え、というオワコンプログラマが多いのさ。

**デフォルトの名無しさん** · 2014/12/07(日) 10:04:52.37

最近のシステムではないと思うけど、ファイルの場合は排他ロックしたらシェルから見てデッドロックしたりするので解放しないという選択肢はないはず。

**デフォルトの名無しさん** · 2014/12/07(日) 10:13:48.44

昔はOSの設計上、同時に開けるファイルハンドル数に厳しい制限があった
今はほぼ制限なしに等しくプロセス外にまで支障をきたすほどたくさんファイルを開くシステムも稀
プロセス間で同じファイルを扱うケースも実際には少ない

**デフォルトの名無しさん** · 2014/12/07(日) 10:45:17.82

たしかに MS-DOS でも1プロセス20までだったか、プロセスメモリマップにもそういうテーブルがあったね

**デフォルトの名無しさん** · 2014/12/07(日) 10:52:54.31

>>595
たしかに、きっちり malloc() と free() を対応させる技術がなく、当然必要がなくなった時点でさっさと free() することもできない、したがって free() しなくともよい判断は到底不可能という、頭の可哀相な >>558 もいることだし

**デフォルトの名無しさん** · 2014/12/07(日) 11:05:32.98

ファイルロックの方法によるのにあっさり決めつけてしまってるあたりが、
全くわかってないことを露呈していて趣き深い。

**デフォルトの名無しさん** · 2014/12/07(日) 13:04:46.31

ちょっとしたgcぐらい、自分で作れよ
gcnew?知るかそんなの

**デフォルトの名無しさん** · 2014/12/08(月) 10:37:40.97

日本主記憶解放戦線。

**デフォルトの名無しさん** · 2014/12/08(月) 17:49:26.49

>>602
こまめにmallocしまくって自滅フラグｗ