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

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

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

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

>>576

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

日本主記憶解放戦線。

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

我々はすべての主記憶を解放するまで戦い続ける。

解放すると遅い。
それは設計あるいは使用範囲が間違っているのである。

適宜開放することにより、誤りに気付く機会が与えられる。
すなわち、確保した記憶域は必ず解放されねばならない。

（主記憶解放戦線憲章より引用）

ムダにかっこいい系

>>603
こまめに free() することにどんな自滅パターンがあるというのか？お前も頭の可哀相な >>558 の同類か？

>>593
終了時の開放は別に無くても良いと思う。

勿論反復ルーチンでは都度開放しないといずれ枯渇するから開放は当然。
GC無くても如何なる場合も開放不要、みたいな意見には賛成できない。

要はケースバイケース

>>607
貴様は己の能力を過信しすぎている。

必ず解放しろ。
いいな、これは命令だ。

信者召喚ｗｗ

計算指示書作成手順において、記憶域解放が省略されてはならない。

それは省略ではなく手抜きである。

少々の手抜きが計算指示全体に悪影響を及ぼすことがある。
心して作成せよ。

サッカースタジアムは、
客がはけた後には必ず掃除されるんだから、
サポーターがゴミ拾いをする必要はない。

しかし同じ日に繰り返し何試合もやったら次第に人のいる場所がなくなるだろ

>>ID:i9BKJ0vK
はっはー。サタンサマー。

組込ソフトウェアでfreeしなかったら、起動してネットワーク接続したら3分と持たずにフリーズするかメモリ枯渇エラーのログ吐きまくるわ

俺の知っている、という枕詞が省略されている典型例やな

free要る派
→自分でしたうんこは自分で流す派

free要らない派
→うんこしたけど、この便所二度と来ることないから俺シラネ
便所の管理人が勝手に掃除してくれるんじゃね？

と考えると、俺は断然free要る派となる

>>616
流すまでその便所は他の人が使えないわけだが、管理人が来ないまま使える空き便所が無尽蔵にあるという前提が必要だな

それが無尽蔵にないからswap地獄に陥るんじゃないか。

管理人がやって来る明確な規則がイマイチわからなくて気持ち悪い

大抵は「管理人仕事しろボタン」があるだろ

>>553
＞信者信者言うのは
自称だと思うよ
絶対というわけではなく細かい点で要不要が議論されることはあるからね

fj.comp.lang.c++
Malloc and Free
https://groups.google.com/forum/m/#!msg/fj.comp.lang.c++/G4HRnHTdImg/pTgn9kQaMCoJ

>>622
懐かしい、あれから 15年かぁ

けっこう最近（？）の話なんだ‥面子的に1990年〜1995年くらいかと思っていた

>>624
Qちゃんfjに参加してたの？
QちゃんC/C++宿題スレで勉強始めたような28才くらいの若者かと思ってたけど（煽り抜き）
意外と古くからML読んでたりしてたの？
おどろき

>>625
＞C/C++宿題スレで勉強始めたような
この部分は当たり他ははずれ
もう7, 8年くらいにはなるな‥
成長が遅いのは頭が悪いせいから仕方がない

15年経っても同じような屁理屈をこねる者がいるというのは感慨深い