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/01/30(水) 21:42:04.63
ここまでのまとめ
・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
・freeいらない派のくさおがバグ付スタックオーバフローソースを作成、
　身をもってfreeは危険だと主張
・freeいらない派のくさおが自演を開始、自画自賛を始める
・freeいらない派のくさおが自演を指摘され遁走　←いまここ
2013/01/30(水) 21:42:28.73
前スレ1


1 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/13(火) 22:12:13.29
前提１：一般的なC言語（GC搭載していない）
前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある


これがメモリリークするのは当たり前の話で、
mallocをしたらfreeするのは当たり前。

free不要論とは一体何だったのか。

天邪鬼（バカ）が言葉尻を捉えていただけではないだろうか。
まつもと ゆきひろもそのバカの一人だったらしいね。

例外中の例外を除いて、mallocをしたらfreeは必要。
これが真の答えだろう。
2013/01/30(水) 21:44:23.19
freeいる派の主な主張
・mtraceが通らないとか論外
・対にするようにしておかないと悪癖が身に付く
・そもそも最後にまとめて解放すること自体が論外

freeいらない派の主な主張
・freeでバグる可能性があるから解放したくない
・プロセスの終了処理に黙って解放されるほうが終了処理がはやい
2013/01/30(水) 22:06:09.81
なんかスレ立てたら賢者モードになっちゃったよ。
前スレで議論してたのがうそみたい。


ところで、Perl、Python、RubyなんかのP言語が猛威をふるい
Javaなんかもガベコレ積んでるし、
Windowsアプリの主要開発言語もC#になろうかとしている今、

今後、手動でメモリ確保、メモリ解放しなきゃならない環境ってのは
どういうのが残るかなぁ

AppleのObjective-C、組み込み開発、ドライバ、OS等のハードに直結した部分
数値計算とかそういう純粋に速度が要求される分野

思いついたのはこのくらいなんだけど
他にないかなぁ
2013/01/30(水) 22:15:43.17
Objective-Cは最近は手動じゃないっぺ。
2013/01/30(水) 23:29:05.06
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
8デフォルトの名無しさん
垢版 |
2013/01/31(木) 06:30:05.64
freeする前に終了しちゃえばいいさ
2013/01/31(木) 07:58:46.76
「main 以外」なんだからねっ！
不毛な議論しちゃダメ、絶対。

ところで、exit 適用時も議論対象外に、入りますか？
2013/01/31(木) 10:16:50.76
「main以外」抜いたここは別スレだろ
11デフォルトの名無しさん
垢版 |
2013/02/01(金) 03:11:22.90
こっちが本スレで向こうが隔離スレでしょ
この議論はUNIXの"悪習"が元凶のような気がしてきた
2013/02/01(金) 21:24:43.72
ぶっちゃけ2000年問題と同レべの手抜き習慣
2013/02/01(金) 23:42:42.74
俺もOS評価するときにOS再インスコが
必要になったらPCの電源をブチっと
落とすけど、そんな感じ？
2013/02/02(土) 09:39:47.82
使い捨てのプログラムで、コンパイラみたいな一度走って終わりのプログラムなら、
全部mallocしっぱなし、ってこともある。時と場合による。
2013/02/02(土) 10:41:02.65
"main以外"を抜いて、また１からやり直したいのか？>>1は
2013/02/02(土) 10:42:00.23
>>13
どっちかというと、再インストール関係なしに「もうディスクにアクセスする必要が
ないことがわかっているから」といってrebootのかわりにリセット押すのが近いだろう。
2013/02/02(土) 23:13:35.87
スレチだが、
sprintf(buf,…);
len=strlen(buf);
という低脳なコードを久しぶりに見たw
2013/02/02(土) 23:27:39.79
946 ：デフォルトの名無しさん：2013/01/29(火) 22:41:57.29
そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。
最後にまとめて解放するくらいならプロセスの終了に任せれば、って
話になるのはそのため。

mtraceの話も出てるけど、リストだろうがツリーだろうが、使っていると
認識している箇所だけを正しく解放していって、最後に何が残るかを
見ないとリークしてるかどうかなんてわからないだろ。

最後にツリーまとめて消してみたら全部消えたのでリークしてません、
なんてことにはならないんだから。
そこに解放したつもりになっているデータが連結されているかどうか
というのが重要なのに。

947 ：デフォルトの名無しさん：2013/01/29(火) 22:45:04.83
こりゃまた大きな釣り針だな。ｗｗｗ

948 ：デフォルトの名無しさん：2013/01/29(火) 22:47:30.66
くさお悔しくて絶好調だな

949 ：デフォルトの名無しさん：2013/01/29(火) 22:47:59.75
>>946
まとめて消して消えるならリークしてないだろ。バカか。
2013/02/03(日) 00:20:47.51
>>17
それやったことあります。汚物見せてごめんなさい。
2013/02/03(日) 06:27:33.11
>>17
そういうコードが必要な場合もある。
どういう場合かは、あんたには分からんだろうがね。
2013/02/03(日) 06:33:39.57
100%ありません
2013/02/03(日) 06:45:51.40
>>21
1行目と2行目でbufの内容が変わることは100%あり得ない

と思ってんだろ？素人君
2013/02/03(日) 07:38:05.86
>>22
はい。100%あり得ません。
bufが共有であるならセマフォなり何らかの排他をしないのは単なるバグです。
2013/02/03(日) 08:04:22.63
>>17
俺も数えるのめんどくさくてやってしまいそうだが。正解は？
2013/02/03(日) 08:20:18.25
>>23
あれを見た瞬間にその「単なるバグ」の可能性にまで気づくかどうかの問題
後出しでは意味なし
2013/02/03(日) 08:34:17.19
>>25
>そういうコードが必要な場合もある。

じゃあ後出しでない回答を期待します。
逃げたければ逃げてもいいですよ。
2013/02/03(日) 08:38:32.01
>>26
もう答えはでている
あんたが理解できていないだけだ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況