始まった！malloc and free - fj.comp.lang.c

徐々に成長しています。
http://news.dinf.ne.jp/news/fj/comp/lang/c/thrd10.html

よく飽きないなぁと関心しております。>>Junn Ohta

おれはデストラクタお任せ派なのでカヤの外(藁

¡¡¤³¤Î²ñÏá¢\꡼\¯¤·¤Æ¤Ş¤»¤ó¡©

¡¡¤Ç¤Ï¡¢

>>4
ヌ、ナキニイーハウー

>1
まるで台風情報みたいだなよ

!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c

!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c!!?3?I2nIA!¢\e!?\￣?・?A???≫?o!c

半年ぐらい前もやってたよな。
しかも、同じような質問で

>>3 これで君も仲間だ
newで生成したオブジェクトは、deleteで破棄する
と思いますが、このdeleteを行わないで、そのプログラ
ムを終了させたら、生成したオブジェクトは残ってしまう
のでしょうか？

私はWindowsNT4+VisualC++6でプログラムを作っている
のですが、deleteを使わない（コーディングミス）時は
どのようになるか疑問になりました。
少し調べたのですが、Windowsだと解放されない場合
があるような記事がありました。他のOS（UNIX）で
はどうなんでしょうか。

また、メモリの消費量を知る方法は何かありますでし
ょうか？

ご指導をいただければ幸いです。

おれはJavaでGCお任せ派なのでカヤの外(藁

deleteは無条件でやらないとだめだろ。
メモリの開放だけじゃないんだから。

おれはC/C++でスタティックなのでカヤの外。(藁

>>10
UNIXだとmalloc()が中でbrk()やsbrk()使ってOSからメモリを
貰ってやってるのが普通だと思うな。で、終わったらプロセスに
関連するメモリを開放する(他プロセスと共有している部分は残す)。

Windows でメモリ開放がおかしくなるのは Windows のバグ
なんじゃないの?

MS-WORDさんは死んでもメモリを離しませんでした。
なんつて。

C++でnewしたやつをdeleteしないのは危険だろ。
デストラクタ呼ばれなくなるし。

こんなんあったけど(藁
http://www.hajimeteno.ne.jp/cgi-bin/tree_bbs/bbs.cgi?num=4029&ope=sel&id=

こっちのMLは朋子嬢のMLと比べて厳しいレスがポンポン帰ってくるなぁ〜
見ていて気持ちがいいね！
この人達が朋子嬢の相手してくれればいいのになぁ・・・

あの ML は朋子の ML じゃねーよ(藁

>>17
ネタかも知れないけれど、MLじゃないよ。

えっとですね、知ってる人は知ってると思いますが、UNIX系では
new (普通はmallocですね）したらbrk (sbrk)してメモリとってきます。
これはそれを実行したプロセスのデブ化を意味するわけです。ヒープが太るんですね。
さてdelete した場合はどうでしょうか？ これも実装依存ですが，普通はfreeが
呼ばれます。ではfreeは？ これはですね、ヒープの管理領域に未使用マークを
付けるだけです。未使用リストに繋げたりしますが。この領域をOSに戻す、
すなわちプロセスをダイエットさせることはあまりしません。
次回のmallocの時に再使用します。つまりnew/delete や malloc/free をキメ
細かに間違いなくしても、プロセス全体でみればサイズは単調増加になります。
なぜこんな仕様なのでしょうか？ それは非同期にfreeされたメモリをbrkなどで
プロセスに返還できる可能性が低い割にチェックに負荷がかかるからです。
メモリ確保の用途に予測可能な規則性がある場合はそれ用の実装をすることは
ありますが、あくまで汎用のnew/delete の場合は上記のようにＯＳから取るばかりで
返還しません。
Windowsは知りません。教えてください。

>次回のmallocの時に再使用します。つまりnew/delete や malloc/free をキメ
>細かに間違いなくしても、プロセス全体でみればサイズは単調増加になります。
>なぜこんな仕様なのでしょうか？ それは非同期にfreeされたメモリをbrkなどで
>プロセスに返還できる可能性が低い割にチェックに負荷がかかるからです。
>メモリ確保の用途に予測可能な規則性がある場合はそれ用の実装をすることは
>ありますが、あくまで汎用のnew/delete の場合は上記のようにＯＳから取るばかりで
>返還しません。

だから何? >>20

>>21 「だから何? >>20」

そうそう、最後に
「プロセスが死んだら太りに太ったメモリは(deleteしてなくても
してても）解放されます」
ってことですね。それが１０さんの質問かな。

良く誤解されるんですが、free なり deleteなりしてればプロセスは
太らないと。そうではないということです。（Unixでは）
ちなみにLinuxなどではどうなってるか知りません。

で、現在のプロセスが充分小さいと思って fork() なんかすると
エライ目にあったりします。常駐型のプロセスではdelete, free
などとは違う方法でそれを回避したりします。

このあたりもWindowsではどうなのかおうかがいしたいです。

烏有さんを発見

要約すると
ANSI規格的にはfreeは必ずしなくても良いが・・
　実はメモリはOSに後始末を任せるしかないから
クラスライブラリではdeleteはしておいた方がいい・・
　オブジェクトが確保したリモートハンドルなどは解放しなきゃ逝けないからね
　だから、メモリ(やファイルハンドルなどOSがきちんと管理しているもの)
　以外は確保していないのが確実なオブジェクトも
　必ずしもdeleteする必要がない

なんだけど厨房には確実にfreeさせておいた方が無難
windowsはバグバグだからやっぱりfreeしないとダメっぽい

で、話しが混乱している
てな感じでしたっけ

>ANSI規格的にはfreeは必ずしなくても良いが・・

ANSIの規格って、「どうプログラミングするか」って指針まで
盛り込まれてるんですか？

は、ともかく、
ちゃんと自分で後始末するのが、良い癖よ。

う〜ん、自分はＤＯＳ時代から先輩には「malloc()とfree()は対で使うべし」と
教え込まされたなあ。
プログラム（プロセス）が終われば解放されるといっても、うちの作るソフトは
たいてい３６５日２４時間ずっと動きっぱなしの監視システムだからだったと
思うけど。

今、１で紹介されてる議論よんできたよ。
なかなか面白いね。
メモリリークと
malloc & free
は直接関係ないんだね。

>>22
>で、現在のプロセスが充分小さいと思って fork() なんかすると
>エライ目にあったりします。
ふつーforkしてもコピーオンライトだから、ちょっと走って
すぐ抜ける子プロセスならページはそんなに使わないのでは。
ページエントリは食うけど。

プロセスを太らせないために、メモリ食いな処理をする前にfork、
処理が終わったらexitとかはやりますが。

ちなみに、Win32 APIにforkに相当するものはないと思う。
あと、Windowsと言っても、9xとNTは中身がぜんぜん違う。
NTならメモリの未開放ぐらいでは問題にならない。というか、
メモリの割り付け方法から言っておきそうもない。

ログあんまりまじめに読んでないけど、
free()は呼ばなくていいし実際呼んでない。って奴はいないんだろ？
ほんと2ch以上にくだんない議論をよく飽きずにやってるよ。

え〜 long durationなプログラムでは、初期化以外でmalloc族は使わないように根性で書くけどな……

>>30
途中でメモリを確保しないってこと? そりゃすごいねぇ

俺もコンシューマのゲーム開発で一回やったよ。
バッファをいくつかの配列でとって使いまわすの。
これはメモリリークではなくヒープの断片化（結果的にmalloc
できなくなるのである意味メモリリークと言えなくもないけど）
の問題だけどね。

なるほど、使いまわすのですか。なるほど。
だけど結局気をつけてメモリを管理しなくちゃいけない事になるし、
(しかも使いまわすとなると相当複雑になりそう)
あまりうまみがある方法とも思えないんですけど…

んーと、
むつかしいことはよくわからんけど、
freeの動作はmallocが再度利用できるように
mallocが利用していた領域を解放するんで
必ずしも＝「OSに領域を返す」て意味ではないのである、
そういう意味では必ずしもメモリリークを防ぐための手段とは
なり得ないのであるるる、
なかには、結果的にそうなる実装のコンパイラとOSもあるかもね、
ということでよいか？

了解しました。
つまりちゃんとしたOS・コンパイラであれば
for(;;)
p = malloc(1);
と
for(;;){
　p = malloc(1);
　free(p);
}
は意味的に同じで、どちらもメモリリークしないということですね。
なっとく。

＞３４
上のやつはだめだよう。
ヒープがたりなくなるよう。
まぁ、それをリークとは言わないよね
実際確保している領域だから。

ごめん、＞３４じゃなくて＞３５ね、アハハ、、

>あまりうまみがある方法とも思えないんですけど…
開発者には何のメリットもないけど、
とにかくメモリ使用量を減らすのが最優先なんです。
X-BOXでちょっとは緩和されるのかな。

そいや jdk1.1 系の JVM って、
ガベコレしたメモリをシステムに返さないで抱え込んどくよね。
けっこう迷惑。
すれ違いで迷惑sage

＞そいや jdk1.1 系の JVM って、

jdk１。３とかは問題ないのかしら。

ていうか、

「freeしてちゃんとその場でOSに領域返してくれたら多い日も安心！！！！」

と、いうわけである。うむ。

Delphiは大きな領域をGetMem, FreeMemすると
ちゃんとその場でOSに返すよ。

>40
NTでは大丈夫だったよん。ついでにThreadに無駄にでかい領域
割り当てないようになったみたいなので、今死ぬほどThread
上げまくって遊んでみてます。

つーか、リークの定義って何？
なんか交錯しててよく分からん。
私の定義は、「確信犯以外の解放し忘れは全部リーク」
メモリだけじゃないよ。

メモリに話を限ると、free/deleteの動作はライブラリ依存なんだから、
OSにきちんと返したかったらネイティブAPI or システムコール使え

>>44
上位アプリケーションレベルでは普通やらないよね。
ＪＶＭとかデバッガとかＶＭＷＡＲＥ？とかシステムに近いところ、
「環境」みたいなもの、クリティカルなものは当然使い分けるべき
だけどね。

>>41-42
いや、だから free していちいちＯＳに返してたら遅くてしかたないよ。
ある程度のチャンクサイズでとって、その中は使いまわすのが順当。
今のmalloc,freeはその「チャンク」が標準では１個（下方単調増加）
だってこと。スタックみたく確保した順と逆順に解放されることが
保証されるような状況の場合は部分解放可能だけど、一般には困難だし
そのためのチェックの負荷が見合わない。
>>42 さんの言ってるものは４バイトとか２０バイトみたいな細かい
malloc, freeが非同期に何万回も来るときに使うものではない
ですよね？ むしろある程度のタームで使う大きめのチャンクとして
という意味ですよね。もし本当に超高速にＯＳに返せるのなら
malloc/freeやnew/deleteの実装につかえるでしょうが、あり得ない
と思います。

>>46
GetMem,FreeMem はC言語で言うmalloc/freeと同じだよ。
Delphi のメモリ管理関数は GetMem/FreeMem が基本。

ソースコードを見てみたが、FreeMem 関数内でVirtualFreeを呼ぶコードが
あるので領域をOSにすぐに返すことはやっているようです。

ろくに調べずに否定するのはどうかと思うが。

ごめんね。ろくに調べずに否定しました。

すごいなWindows。 p=malloc(4); free(p); したメモリ、マジで
他のプロセスがソッコーで使えるってことか？ よくそんなで実用的な
スピード出るな。。ゲイツかカトラーか知らんがすご過ぎ！
トンプ孫もびっくりだ。

ところで VirtualFreeってシステムコールなの？
ただのapiライブラリなの？
システムコールなら、どんな挙動するものなの？
apiなら、中は free みたいなものではないの？ 違うのかな？

>>48
そのかわり安定性が犠牲になります。

>>48
ページが解放されれば速攻つかえるだろ。

ニュースグループの人たちはキディガイですか？
一般社会でまともに生活できなそうですね。

いやな、

void f()
{
　 　int i;
　 　char *p[4];

　 　p[0] = (char*)malloc(4);
　 　p[1] = (char*)malloc(10);
　 　p[2] = (char*)malloc(1);
　 　p[3] = (char*)malloc(20);
　 　…
　 　free(p[1]);
　 　…
}

ってしたときに、大まかに言ってp[0] 〜 p[3] は連続領域に割り当てられる
だろう？ アライメントにもよるけど、まあ大体近所にとられるわけだ。
この free(p[1]); されたメモリを、その直後に他プロセスの malloc(10); とかが
もらえる、なんてこと、あるの？ 信じられんな。 どんな管理してるんだ？

>>53
断片化の話ですか?

>>42 「大きな領域をGetMem, FreeMemすると ちゃんとその場でOSに返す」
>>47 「FreeMem 関数内でVirtualFreeを呼ぶ…領域をOSにすぐに返す」

とあったのですが、そうするとフラグメント化した領域でもOSに返すのか
なと思って。そんな仕様がまともなスピードで動くとは思えないので、
VirtualFreeというのは、実は Cの free みたいな仕様なんじゃないのかな？
って思ったわけです。
Windowsに疎くてｽﾏﾘ

malloc/free論争って要するに規格を拡大解釈することを良しとするかしないかを争ってるんですよね?

>53

だから、「ページ」が解放されたらっつたろ。
OSの仮装メモリってのはページ単位（Winは4kb）でメモリを管理してる。
で、割り当てた「ページ」を解放すれば別のプロセスがその「ページ」を使えるんだよ。
たしかVirtual系APIはそのページの取得／コミット／解放を扱うためのものだったはずだ。

ただし、Winのmalloc/freeはＣランタイムで独自のヒープを使っているはずなので
Virtual系のようなページ解放は行われないはずだ。だから解放しても即再利用されることはあるまい。

どうしても即再利用を行いたければ自分で仮想記憶を管理するべし。面倒だけどさ。

Win32だったら、Heap系のAPI使った方が楽は楽。
使いたいときにヒープオブジェクト作って、そこからちまちまアロケート。
要らなくなったらヒープオブジェクトを解放すれば、すぐにOSにメモリが
返せる。
HeapCompactなんてAPIもあるしな〜。可能ならdecommitするよ。

というか、VCのCRTにあるmallocは、ヒープの中身を更に自分で管理している
わけなんだけども。考えるこたぁみな結局同じなのよ。

>>53
一般のアプリではページごとに局所化されるように意識して描かない
ですよね。それともDelphiでは４Kを意識してヒープ使うわけ？普通。

そうじゃないとしたら、Freeみたいなライブラリが中でVirtualFreeとかを
呼ぶことはあるかもしれないけど、アプリケーションプログラマが
直接VirtualFreeすることはなさそうだなあ。特殊な用途なら別だけど。

だとすると、結局 じゃ Free みたいなのがいちいち４Kバイトまとまって
解放されたかどうかチェックしつつ走るのは負荷だと思うな。
違う？ WinのCランタイムはそうしてないと思うけど（UNIXはしてない）
Delphiはどうなの？ そういう上位メモリマネージャを普通使うの？
それともアプリケーションプログラマが普段VirtualFreeとか使うわけ？

メモリリークの定義は
どこからも論理的に正則には参照できない領域が
残ってしまうこと
をいうのではないかい？

>>35

for(;;)
p = malloc(1);

２回目の malloc() で最初の p の値が上書きされた時点で
その領域は「リーク」というのでは？

Delphi はC言語ではない、つまりANSI C規格とは全く無関係だから
そこをふまえておいてな。

>>59
くどいようだが GetMem/FreeMem は Delphi の基本的なメモリ管理関数だ。
プログラマはページのことを考慮する必要は全くない。
クラスのインスタンスやstring型もこの関数でメモリを確保する。

本気でソースを読むつもりはないから無責任なんだけど、
GetMem.incをちらっと眺めると、
InsertFree,MergeCommit,WalkHeap,AddBlockAfter,...
みたいに、自前で管理しているとしか思えない処理があるんだけど。
見るところ間違ってる？

FreeMemで解放されるのは、
・一括確保したブロック内の全てが未使用になったらOSに返す
　(絶対にOSに返さないで再利用を待つ実装もある…JVMも？)
・64Kとか256Kとかのしきい値を決めて、
　その大きさ以上のブロックは自前の管理から外す
等のやり方と思えるんだけど。
自前で管理しているのなら、「FreeMemを呼ぶたびにOSに返す」というのは
何か違うような。

いや、言いたいのは、
「OSに返しているか」じゃなくて、
「(遅いから)毎回OSを呼んでるわけじゃないでしょ？」
ってことなんだけど。

なんか勘違いしてたらごめんね。

>>60

それはコードを書いたプログラマの問題でないかな。
実際には利用できないわけだけど
プログラマの意図は確保なんだから。

「freeがリーク回避手段になるか」
という議論とは関係ないんでないかちら。
まぁ、リークの定義っていうとちょっとややこしいわよね。

アンド、おそらく議論が混乱してゆくのは
どっちが効率がよいとか、あるＯＳのメモリ空間の扱いとか
freeの機能とは関係のない話をしてしまうからよね。

そして、長レスになってしまうが、
freeしても再利用されることが期待される領域が開放（解放？）されるだけで
実際に再利用されるかどうかはfreeのしったことじゃないんだわよ。

「VCだと開放して無いメモリ」の事を「リーク」と称している感じ。

>>61
ということは、Delphiではアプリケーションプログラマが
４バイトほしいときも２００Kバイト欲しいときもGetMemしてるってこと？
そして（普通は）deleteとかfreeと同じ感覚でFreeMemしてるってこと？

で、FreeMem はシステムコールではなく単なるライブラリで、内部で
ページバウンダリチェックして自動的に解放するの？

ちょっとオーバースペックのような気がするけど。汎用としては。
それに >>41 の「FreeMemするとちゃんとその場でOSに返す」というのは
少し違ってないですか？？？
なんか混乱してきた… 鬱だ氏のう

>>64
メモリ確保したとたんリーク呼ばわりなの? うそーん

Delphi のメモリマネージャは，たとえばオブジェクト指向アプリケーションや文字列データを処理するアプリケーションなど，小さめなサイズの多数のブロックを割り当てるアプリケーション用に最適化されています。そのために，その他のメモリマネージャ，たとえば GlobalAlloc，LocalAlloc の実装や Windows でのプライベートヒープサポートなどを直接使用すると処理効率がよくないので，アプリケーションの処理速度が低下します。
最大限の処理効率を確保するため，メモリマネージャは Win32 仮想メモリ API（VirtualAlloc 関数と VirtualFree 関数）と直接やりとりします。メモリマネージャは 1 MB のアドレス領域を単位としてオペレーティングシステムからメモリを確保し，必要であれば 16 KB 単位でメモリをコミットしていきます。メモリマネージャは未使用のメモリを 16 KB と 1 MB 単位でコミット解除し解放します。もっと小さいブロックの場合，コミットされたメモリがさらに分割割り当てされます。

>>66
確保してそのまま使われずにほっておかれるってことじゃないの？

>>47より
＞ソースコードを見てみたが、FreeMem 関数内でVirtualFreeを呼ぶコードが
＞あるので領域をOSにすぐに返すことはやっているようです。

OSにすぐに返すことはやっているようです、か。

＞ろくに調べずに否定するのはどうかと思うが。

まったくだよ。

ま、mallocもいろいろあって、ちゃんと内部で賢く使いまわししているのも色々ありますね。
最近は
http://reality.sgi.com/boehm_mti/gc.html
というのもあって、使ってみたいのだけど機会がなかったり。

>メモリ確保したとたんリーク呼ばわりなの? うそーん

それを解放しないまま実行を終えたら、だよ。

>>71
なるほどそう読めますね。なっとくしました。

67の引用元はどこだろう？
46さんの最初の２行は67の後半と同じ事を言っていると思うんだけど、
それを否定してる41&47&61さんの反論待ちですね。

本題に戻って、
以前、同じくfjのこの話題でスレが立った時に紹介されていたリンク。
http://www.amy.hi-ho.ne.jp/~lepton/program/p1/prog121.html
http://member.nifty.ne.jp/maebashi/programmer/c_yota/malloc.html
特に下のリンク先の考え方は興味深いものがあります。

>>66
言い方悪かったッス。
プログラム終了時に開放されて無い「new」「malloc」したメモリ領域が
残ってる場合、に訂正。
リソースは検知出来ない模様。ショボ！

終了時にfreeしてようとしてまいと、
解放するしないはOSの責任だずら。
それ、mallocの話じゃなくなってるジャーン。

>解放するしないはOSの責任だずら。
あれ、この手の議論は
「終了までの間に必ずfreeすべきだ」対
「終了時にOSが解放するから、freeは必要ない」でしょ？

>mallocの話じゃなくなってるジャーン。
話がそれてるんじゃなくて、本質じゃん。

ごめん、リークの話題だってことに気がつかなかった。

それてるなんていってないジャーン。

だが、本質ではないよ。

何度もいうけど、「free」と「終了時にOSに領域が返る」かどうかは
直接関係ないんだってば。

てなことはかの板でも繰り返し言われているにもかかわらず
話が長引いてしまうのはそこらへんをナイマゼにして
焦点ぼやけるからでしょ。
答えはシンプルだっちゃ。

「終了までの間に必ずfreeすべきだ」
「終了時にOSが解放するから、freeは必要ない」
この二つの主張は

●繰り返しmallocするようなプロセスでは必須の場合もあるし、
●そうでなければ不要である。

で、どちらとも正しいと言えるしどちらも間違っているともいえる、

そしてこの話そのものは終了時リークとは関係ない。

またコード中に参照できなくなるmallocで確保した領域があって
それをリークと呼ぶとしてもそれはmallocとfreeそれぞれの仕様とは
関係のない「プログラマの責任」である、

というのではダメかね。

>>79
追加
「exit()直前のfree()は不要である」
これは正しい？

>80
>追加
>「exit()直前のfree()は不要である」
>これは正しい？
間違っちゃいないけど、他のプログラマが不安と混乱に陥るから、
せめてfree()を書くべき場所に
/* ここには本来free()を書くべきであるがexit()直前なので省略する */
というコメントを入れといて欲しいな(藁

＞解放するしないはOSの責任
とは、「freeしてなくても、OSが解放する義務がある」という意味か？
アプリケーションにあわせてOSを作れと。
解放を忘れてリークが起こっても、悪いのはOSであり、
コンパイラもライブラリも、もちろんプログラマも関知しないと。
極論すれば「プロセス終了時に領域を解放しない物はOSと呼ぶな」だね。

きみの考えが「OSが解放するからプログラマは解放しなくても良い」
なのはよくわかる。実際、俺もプールした領域は大抵解放しない。
つまり、俺の考えも同じ。

でも、論点は「OSが解放する保証があるのか」だ。
「プロセス終了時に領域を解放するようにOSが作られているのか」だ。
これが論点なのに、前提にしているのはおかしい。

そんなコメントいれるなら素直にfreeしたほうがはやいわね、ホホホ

(freeされなくても)終了時にプロセスが確保したメモリを解放する、
これはどのような実装でも保証されるのか？
freeしなくても良い理由は、OSがそう作られているからであり、
OSもライブラリも違う作りになっていたら前提が崩れる。

例えば、貧弱なOSで、確保したプロセスを記録せず、
常に明示的に解放しなければ空きとして扱わない場合。
この場合は、プログラマが全てfreeし、
(その結果として)ライブラリがOSに返さなければ、解放されない。
(もちろん、組み込み等のきわめて特殊な環境しか存在しないが)

だから、「OSがプロセスが確保した領域を全て解放するなら」
という前提条件がなければ
＞「free」と「終了時にOSに領域が返る」かどうかは直接関係ない
とは言えない。

mallocで確保したメモリに限れば、現実にはその通り。
だが、FILEは？SOCKETは？HANDLEは？displayやprinterは？
メモリに限らず、気持ちの持ち方として
「確保したリソースは(全て)責任を持って解放すべき」
と考え方があるから、議論が再燃するのだろう。

あら、すれちがい、ちょっとおまち。今よむわよ。

またすれ違っちゃったらごめんね。
俺も、Winにしろ、Unixにしろ、現実には
(少なくともメモリに関しては)解放してくれるのを知っている。
だから、実際面倒な事はしない。
上の例でいえば、exitの前やmainの最後でfreeなんぞ絶対しない。
(fcloseはちゃんとする…忘れなければ)

けど、人に教えたりする場合は躊躇する。
「解放しなくていい」とは(知ってはいても)言いたくない。
…我ながら矛盾しているが、本音はこんなところ。

あおるつもりはないのだけど、
おっしゃってることがよくわからないわ・・
ていうか、アタシの話を論証しているようにしかみえないわ。

気になるのは
＞＞解放するしないはOSの責任
＞とは、「freeしてなくても、OSが解放する義務がある」という意味か？

そういう意味じゃないわ。
あなたが論証しているじゃないの、「特殊な環境」
も実在するでしょ。
freeはfreeの役目を果たしているのよ。
それがその環境の場合「OSに返す」ことになる。
だから環境次第よね
それをアタシは
＞＞解放するしないはOSの責任
と表現したのよ。責任なんて言い方したからまずかったのかしら。
（OSとひとくくりにしてしまうのも問題かとは思うけど
　細かいつっこみはなしよ。）

＞でも、論点は「OSが解放する保証があるのか」だ。
＞「プロセス終了時に領域を解放するようにOSが作られているのか」だ。

そういう風につくられているものもあるし、
そうでないものもある、
つまり
＞＞解放するしないはOSの責任（→しだい） ・・・

もういいわね。はずしたレスだったらいってちょうだい。
返事に困っちゃったわよ。

長々と書いてしかもサゲちゃったじゃないの、、、、

アタシの書いた文章、論理がおかしいわ、、、
まぁ、広い心でよんでちょうだい。
いいたいことは変わらないわ。

よくわからない場合はfreeしておいていいんじゃないかしら。
それはそれで問題あるみたいだけどね。

８２＝８６さんのように理解してる人は省略すればいいのよね。
ちなみにアタシはホントは省略しないわ。オホホ

今時の環境で（通常の）メモリが１〜２Ｍリークして、
ＯＳが握ったまま放さなくても、正直困らないわけよ。
そのうちスワップアウトするだろうから。＜しないと困るな・・・

問題なのは容量固定で少ない9xのリソースメモリだよな。GDIとかの。
プロセスのハンドルわかってんだから開放してくれりゃいいのに。
デバッグ中にガンガン減ってくのには参ったよ。
w2kはリソース制限無しなの？今までそれ関係で一度も落ちた事無いし。
NTは制限あった気がしたが・・・確信が無い。

俺が言いたかったのは領域をOSに返却する処理がアプリ終了時以外に
FreeMem関数内でも行われることです。

そういう意味で「領域をOSにすぐに返すことはやっているようです。 」と
表現したのだが誤解を招いてしまった。すみません。

free(malloc(0));

ところで上の方で C の malloc(), free() と C++ の new, delete を
同じものとして書いているように見える書き込みがあるけど、これは同じ
じゃないぞ。 delete はインスタンスのデストラクタを呼ぶんだからな。
その中で更に何かの処理をするかも知れないんだから一緒に考えちゃだめだ。

えー！！
　　　>>42 「Delphiは大きな領域をGetMem, FreeMemすると
　　　　　　　ちゃんとその場でOSに返す」
と
　　　>>91 「領域をOSに返却する処理がアプリ終了時以外に
　　　　　　　FreeMem関数内でも行われることです」

は、全然違うじゃんか (-_-#)

「ちゃんとその場で」ってなによ。。

そんなで >>47 「ろくに・・・」とまで言われたオレっていったい…

氏のう。鬱のせいで。
　　 ∧||∧　　∧||∧　　∧||∧　 ∧||∧　　∧||∧
　　（ / ⌒ヽ （ / ⌒ヽ （ / ⌒ヽ （ / ⌒ヽ （ / ⌒ヽ
　　　| | 　　|　 | | 　　|　 | | 　　|　 | | 　　|　 | | 　　|
　　　∪ / ﾉ 　∪ / ﾉ　 ∪ / ﾉ 　 ∪ / ﾉ 　∪ / ﾉ
　　　 | ｜| 　　 | ｜|　　　| ｜| 　　 | ｜| 　　| ｜|
　　　 ∪∪ 　　∪∪　　 ∪∪ 　　 ∪∪　　∪∪

47は46の内容を理解していたのだろうか。
＞領域をOSにすぐに返すことはやっているようです。
＞ろくに調べずに否定するのはどうかと思うが。
と言った後で
＞誤解を招いてしまった。
間違えたわけではないのか。
往生際もすばらしい。

つーかWindowsよくしらんけど、プロセス終わってリソース解放しない
OSなんてあんのか？ なんのためのOSだ？
そういうことはしっかりやれよ ＞ OS
共産党の作ったOSなーんだ？ OSAKA

>>96
やばいよ〜そういうネタは。
タテジマの宣伝カーがやってくるよ(w

右翼age

>>96
あちきの理解では、WindowsNT とか2000はUNIXなみにできてると
思うんだけど。。。違うのかニャ〜

>99
つーか、UNIX(のコンパイラ)はプロセス終了しないと
取得したメモリを開放できないんでしょ？
Windows NT/2000どころか95以下じゃん（ﾌﾟ

自分で開けたものは、自分で責任持って閉める。
自分で借りたものは、自分で責任持って返す。
プログラミングにおいても、一般常識と同じ。
他力本願は駄目。

選挙にいこう、じゃないわよ、
自分で開けたものが閉めても閉めなくても
閉まらない場合があるって話してるのよ。
閉めて閉まるならこんな話誰もしないわよ。
もう何いってるかわからないわ。

アレ、ちゃうちゃうちゃう？

>自分で開けたものが閉めても閉めなくても
>閉まらない場合があるって話してるのよ。

それは、ドア自体の故障だ。メーカーに言って修理してもらえ。
自分で直せるなら、自分で直せ。

あなたいいこというわね。
でもメーカーは知らん顔だし、アタシには直せないわよ。

>>99
あー、それはアンタがなにも知らないから。
stdのCライブラリの実装にはそういうのが多いけど
そうじゃないのもあるよ。OSの問題ではないんだ。

>>106
もの知りのあんたに質問だ。
UNIX系のOSで「そうじゃないの」の例を挙げてみてくれ。
その「そうじゃないの」はどうい実装になってるか説明してくて。

え？別にオレは物知りだなんて言ってないぞ。あんたが間違ってる
っていっただけだ。
たとえば一例だけどFreeMemと大体同じ方式のもあるじょ〜
BSD系に多かったと思う。ちゃんとbrk(マイナス）するやつね。
それとC でもリンクするライブラリは 規定のlibcxxx.a や.so だけ
じゃなくてもいいです。これも libmalloc??? 系をリンク可能です。
これはいろいろバリエーションがあって、クリティカルな用途の
ために色々な特性のものがあります。
ただどっちにしろ魔法はないですから、メモリデタッチのためには
代価を払うことは同じです。
それからC++ delete のオーバーライドならなんでも可。

カギはそおのアプリケーションが要求するメモリサイズと回数と
割り当て→書き込み遅延レートがどれだけの精度でエスティメイト
できるか、です。
ただ通常はそこまでクリティカルなコンパクト性を要求しないので
システムライブラリ内での自己回収で充分てことです。
永続性の高いもの、組みこみモジュールなど、目的によっては
↑のほうにあったようにヒープを極力避けることもあります。
ヒープ無しでは困難な仕様の場合、初めてカスタムアロケータの
出番となります。
という事情はWindowsだろうがDelphiだろうが同じだと想像してます

それから、こういうメモリマネージャの振る舞いと「コンパイラ」は
まったく関係ありません。

>>108
メモリデタッチとかエスティメイトとか一般的でないカタカナ英語
使うのやめてくれんかのう。日本語にある言葉を使ってくれ。

たとえば一例ですがFreeMemと大体同じ方式のもあります
BSD系に多かったと思う。ちゃんとbrk(負方向）するやつね。
それとC でも結合する機能群は 規定のlibcxxx.a や.so だけ
じゃなくてもいいです。また、libc系の中にあるもの以外にも
libmalloc??? 系を結合可能です。
これはいろいろ多様なものがあって、きわどい用途のために
色々な特性のものがあります。
ただどっちにしろ魔法はないですから、記憶領域の解放のためには
代価を払うことは同じです。
それからC++ new/delete の横取りならなんでも可。

鍵はその応用例が要求する記憶領域の大きさと回数と
割り当て→書き込み遅延の割合がどれだけの精度で予測できるか、
です。
ただ通常はそこまでギリギリの集約性を要求しないので
基本関数群内での自己回収で充分てことです。
永続性の高いもの、組みこみ関数など、目的によっては
↑のほうにあったように堆積記憶領域を極力避けることもあります。
堆積記憶領域無しでは困難な仕様の場合、初めて独自仕様獲得関数
の 出番となります。
という事情はWindowsだろうがDelphiだろうが同じだと想像してます

それから、こういう記憶領域管理関数群の振る舞いと「compiler」は
まったく関係ありません。

>>108 >>110
？
ほとんど同じ内容じゃん。
2重カキコってわけでもないみたいだし。キチガイ？

なるべく日本語になおしただけだろう？
>>109なんか無視すればいいだろｳﾞｧｶ

もちろんキチガイよ。
こむずかしいこと並べられても読む気もしないわよ。

>>110
この書きなおしで分かりやすくしたつもりなんかな？
人に説明するのは苦手なタイプなんだろな。きっと。

>>113-114
わからないから説明してとたのまれてそこそこ詳しく説明したら
難しいだのわかりにくいだの言う。
「分数できなくても人生に影響ない、先公にオレらのなにがわかるんだ！」
といって算数を勉強しない厨房といっしょなので、以後プログラミングは
禁止します。 (ﾌﾟﾌﾟ

>>113
別にこむずかしくないぞ。

>>115 かぶったｽﾏﾘ

皮肉よ。

うざいな他でやれよ。逝ってヨＣ

相手がエンジニアだと思って説明してくれたんだろう
ただの厨房だとわかってゲンナリしてるだろうな・・・
ＲＯＭしてるヤツらもいるから気にすんな ＞１１０

>>115
本当に理解してる人間はもっと要領よく整合性のある説明ができます。

適当に検索エンジンで検索して、文章をつぎはぎして張ったりかます
のは、君の周囲の素人相手ならともかく、こういう場所では、みっとも
ないだけですよ。

じゃオマエやれ >>121

>>122
内容のない煽りはsageでやってください。

>>121 珍しく頭にキタ！
なんでそんなヒマなことしなきゃいけないんだ？
UNIXでどうなの？と聞かれたから、知っている範囲で書き込んだだけ。
気に入らないんならよそで勉強するか、間違いを指摘するかしろよ。
どこだよ？ え？ どこが間違ってて、どこがＷＥＢの資料なんだよ？
言えよこら。

なんで荒れるかね。このスレが。。。
アラシは他でやってﾁｮ >> 121

＞１２４ ほっとけよｳﾞｧｶ
コピペだとしか煽れない事自体、他がわかってないってすぐわかるだろうに…

>>124
だから、sageでやってくれよ(;´Д`)

>>126
だってひどいじゃないかよー！ ムカつかない？
なぜわからないことまで煽ろうとするかなあ。。
もうやめた。どうせこいつらＵＮＩＸなんて一生縁がないんだろ。ムダムダ。ふん

かちゅ〜しゃで簡易あぼ〜んすれば気にならなくなるよ。
どの番号のレスをあぼーんすればいいかのリストを作ってあげるから
それで見てみて！
誰が見ても >>121 は単なる荒しじゃん。あんた２ｃｈに慣れてないんだろ？
ここは確かに少ないほうだけど、やっぱりいるから。こういうの。健全な証拠だ。
気にするな。

106の文章が反感買っただけよ。
皮肉を言っても通じなくて、あげく解答も切れが悪くてイヤミだったのよ。
内容が正しいかどうかってことじゃないわよ。

　　　　　　 ∧ ∧　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′￣￣(　´∀｀）＜　　あーあ、怒っちゃった。ﾏﾀｰﾘ逝こうよ
　UU￣￣　U U　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

おいねかまよ、男らしいところみせろや（藁
１００みたいな間違い放置するよりましだろうが。
１２１も謝っとけよ・・・ ったく

ごめん。あまりに食いつきがよさそうなので、つい煽ってしまいました。

なんでアタシに振るのよ（W

１２１も謝ったし、マターリ進行でいきましょうか。

某国内メーカーのUNIXに携わったものですが
（今はありません ToT） >>110 ほどには
凝ったlibcではありませんでした。
ただし大口の特殊用途向けに別実装のlibcを
出したことはあります。未だに一部稼動していると
聞いています。当時としてはまだ充分実証されて
いなかったリアルタイム・コンカレント・ガーベジ
コレクタを組みこんだマルチスレッド対応版でした。
(ｶﾀｶﾅｽﾏｿ)
その時に他のＵＮＩＸのソースも見ましたが概ね
基本的なところは106さんのとおりでしたよ。
ただし９９％のユーザーアプリが標準のmalloc free
で稼動してました。あまり解放しないタイプ。
当時はメモリがきつかったので、今よりずっと神経質に
追求する場合もあったんです

ところで１２１さんは他の実装をご存知なのですか？
なんかそう読めたんですが・・・
教えてください。私には>>108の説明は一般の理解のレベルではなく
疑問に思った人の理解を充分補うものだと感じるんですが。
あ、私にはわかりやすく説明していただかなくて結構です。
詳しいほうが嬉しいです。

なんだなんだおまえら・・・ ちょっとまてよ。
このスレたどると、
アプリ − サポートライブラリ − システムコール − 仮想記憶空間
の関係性がわかってないやつがいるな。
なんにせよｽﾏｰﾄＸＸでもなんでもいいけど、やった女は池に戻せ、だ。

しょせんWindowsのアーキテクチャはＶＡＸのパクリでしょ。
そんなには変わらないよ。ＵＮＩＸだって。

>やった女は池に戻せ

御意。

１２１、ねかま反省中
厨房さらしsage

なんでアタシが反省中なのよ。
美容院行ってたのよ（ほんとは床屋な）

それはともかくネタ振ったんだから
１３８には話し続けて欲しいわね

この板のレベル、さらしとこう

おいおい もうおわりかよ
なんかないのか？ 具体的な内容なんて１つか２つくらいしか
でてないじゃんかー
頼むぜ自称プログラマしょくん （和羅

> もちろんキチガイよ。
> こむずかしいこと並べられても読む気もしないわよ。

> 106の文章が反感買っただけよ。
> 皮肉を言っても通じなくて、あげく解答も切れが悪くてイヤミだったのよ。
> 内容が正しいかどうかってことじゃないわよ。

ねかま、氏ね

>>144
自分が理解できる事＝具体的な内容と勘違いしているのは痛いです。
理解できないのに下らん煽りをするのはウザイです。
お願いですから消えて下さい。

>>146
そうか？
何番のレスが意味があるのか言ってみろ

>>146
なんだかんだ言って具体的な話には絶対入ろうとしないな。

>>148
ソーダソーダ！
ちょっとは具体的なこといってみろってんだ
つーの

>>147-149
>何番のレスが意味があるのか

>>20 Unixでのメモリ管理
>>67 Delphiでのメモリ管理
>>108 BSD系でのメモリ管理
あと、K&Rにはmalloc/freeの実装も載っているが、これで不足？

ちなみに>>147-149って意味のある発言とは思えないんだが、
そういう内容の無い発言をすると頭も空っぽと思われるから
やめといたほうがいいよ。

身のある話がもっとききたいゾナsage

　　　　　　　　　　||￣￣￣￣￣￣￣￣￣￣||
　　　　　　　　　　||　煽りに　　　　.　　 .∧_∧ 　ｶｯｺﾜﾙｰｲ!
　　　　　　　　　　||　　マジレス..！＼　( ﾟДﾟ.)
　　　　　　　　　　||＿＿＿＿＿＿＿⊂⊂　 |

　　∧ ∧　　　 ∧ ∧　　　 ∧ ∧　　|￣￣￣￣|
　 (　　∧ ∧　(　　 ∧ ∧　(　　∧ ∧ 　 　　 　 |
〜（＿(　　∧ ∧ __(　　∧ ∧__(　　 ∧ ∧￣￣￣
　　〜（＿(　　∧ ∧＿(　　∧ ∧＿(　　 ∧ ∧ 　ｶｯｺﾜﾙｰｲ!
　　　　〜（＿(　 　,,)〜（＿(　 　,,)〜（＿(　 　,,)
　　　　　　〜（＿__ﾉ　　〜（＿__ﾉ 　　〜（＿__ﾉ

>>150
そういうことじゃないんじゃないかな。煽られてるのは。
読んでみたけど、ウソや間違いや厨房の意見が多くて
なるほどと思える書き込みが少ないってことだよ。
まああんまりにも厨房ばかりでマジで書いた人も呆れた
ってとこじゃない？オレも読んだけど２，３わかってる人が
書いたのがあるけど、理解力の無いヤツが難しいだのムカツク
だの書いてる（藁
平均するとこの板のレベルなんてこんなもの。まあ２ｃｈなんて
だいたいそうだ。高校生しかいなくなったクラブみたいなもんだ。
つまんなすぎ

ピークのレベル低くはないと思うよ。
カーネルやコンパイラのソース見てるし、
受け売りだけじゃ書けない記事もでるしね。
よそはどっかのセンセイや雑誌の受け売りのとこばっか。
最低と最高の落差があるのがまた一興でしょ。

>>150
144=20=108なんだけど、気持ちわかってくれる？
他にあまり具体的なものを読み取れなかったんだよ。
自分はかなり具体的に書いたつもりだったので。
紛らわしくてすまんかったが。

敢えて言うけどさ、>>108等を読むと、
>>20
＞メモリ確保の用途に予測可能な規則性がある場合はそれ用の実装をすることは
＞ありますが、あくまで汎用のnew/delete の場合は上記のようにＯＳから取るばかりで
＞返還しません。
が「ライブラリの仕様」であって、「OSの仕様」じゃないってことは
分かってはず。
途中にdelphiがどーたらみたいに混同してる人がたくさんいるけど、
分かる人はわかってるから、>>46とか>>65みたいにあっさり反論されてる。
で、ライブラリの仕様に対して、
>>20 ＞Windowsは知りません。教えてください。
は少し意味不明だな。
これが「Windowsはプロセスが確保した領域を、終了時に全て開放するのか？」
という「OSの仕様」についての疑問なら答えはYesだし、
「Windowsではプロセスの大きさは単調増加なのか？」
なら答えは実装次第・・・Unixと変わるわけがない。

が、プロセスが確保するのはメモリだけではないところが悲しいところで、
(Win用語での)リソース等、「明示的に解放しなければ
プロセスが終了しても解放されない物」があることも示されている。>>90
そして、delete(operator deleteではない)内で
メモリ以外の資源を解放する場合があるから、deleteとfreeを混同するな>>93
と述べられている。これは暗に「確保した資源はデストラクタで解放しろ」
という意味合いも含まれる。

>>22
＞良く誤解されるんですが、free なり deleteなりしてればプロセスは
＞太らないと。そうではないということです。（Unixでは）

これも「ライブラリの実装がそうなっているだけ」…と自分で言ってるね。
int i, *p[1000*1000];
for (i = 0; i < 1000*1000; ++i)
　　p[i] = (int *)malloc(sizeof(int));
for (i = 0; i < 1000*1000; ++i)
　　free(p[i]);
と、
for (i = 0; i < 1000*1000; ++i)
　　p = (int *)malloc(sizeof(int)),　　free(p);
とで、プロセスの大きさに差があるかは「ライブラリの実装次第であり」
「OSによるものではない」・・・OSによる制限がない場合。
この辺りは、中途半端ながら>>53及びそれ以降のページ境界議論の中で
暗に示そうとしているようにも思えるが、それは違うか。

ちなみに、無駄に長々と続けた以上の話、つまり、
OS -> ライブラリ -> アプリケーション
を混同している点は、>>138で明確に指摘されているが、
それ以前から「ライブラリ」「OS」という言葉は使い分けられているはずだ。
(138では、さらにハードウェア -> OSを含んでいる)

もう一つ、「ライブラリの実装」について、>>22の「単調増加」を否定する
事例が>>136で示されている。曰く、
「殆どのライブラリではプロセスの大きさは単調増加であり、
それを利用したアプリケーションも単調増加であるが、
それを良しとしない用途も存在し、そのために実装を変える事があった」


ま、それでもまた>>99-100みたいに「わかってない人」が次々現れるから
嘆いてるんだろうけど、
半年前ならいざしらず、今のプログラマ板のレベルなんてそんなもん。
底辺プログラマの大量流入によって、「平均レベル」は確実に落ちてるね。
でも、>>154の言う通り、「わかる人」が減ったわけではないと思う。
実際、引用レスは全て「俺以外の誰か」が書いたものだよ。

まだ誰にも読まれてないうちに。
158の最後は「自分は底辺じゃないぞ」のつもりで書いたわけじゃないからね。

以前は俺にはついていけないような話の比率が高かったのに、
今は、俺程度でも間違っていることがわかる程度の話題が増えたってことさ。
俺の理解できる範囲が少し増えた点を考慮しても、
板の平均が下がってるってこと。

２ｃｈなんだから、ﾁｭｳﾎﾞｳがなにかと上下関係をつけたがるのも
気に障るほどのことでもないけど、まあ技術系の板なんだから
多少は技術的な情報としての価値を重んじる方向性でやってけば
いいんじゃないの。レベル低いのは別にかまわないけど、
あまりに無用な煽りなんかは、なんていうのかな、もったいない
って感じるけどね。

なーんか、１０８が２０だとすると、ほんとにわかってるの？って
疑問を持つ部分が無くもないような。

108の内容で、
BSD系は〜って部分は、BSD系の標準libcは〜って意味に捉えてたけど、
もしかして、OSによって差があると思ってるのかな？
WindowsとDelphiを同列に並べている理由もよくわからん。
コンパイラに言及してるのも108(106)だけなのだが、
コンパイラのコード生成とmalloc/freeの振る舞いは確かに関係無いが
コンパイラ(リンカ)がどのライブラリをリンクするかによって
同じOSでも挙動が変化する点はどうなのかね。

>>161
２０ですけど、差、ありますよー
BSD系かAT&T系でも違うし、（歴史的に当然だけど）
同じBSD系でもインプリに違いはありましたよ。
SUNとかOMRONとか。全部中見たわけではないですけど。
たとえばSYSTEM V系でも一部
BSD系のライブラリを取り込むとか逆も普通に行われていました。
今はどうだか知らないです。
malloc/free でもbrk(マイナス)する実装のもありました。同じOS内でも
複数提供してた場合もあります。

WindowsとかDelphiとかは全然わかりません。ただ「あるなあ」と
思って使っているだけで。

コンパイラは、だからライブラリのバインドどは何の関係もないけど
リンカが標準でどのライブラリをリンクするのかはもちろん大いに
関係しますよ。
で、「どうなのかね？」とはどういう意味ですか？

１つ気付いたけど、>>106 で >>99 に突っ込んでいるのは
間違いで、>>100 でした。

「OSによって差がある」＝「OSのシステムコールに差がある」ではなくて、
「OSによって標準ライブラリの実装が違う」から、「差がある」でしょ？
それは「OSによる差」ではなく、「ライブラリによる差」と言うんでは無いの？

OSによって違うってのは、例えば
BSD系は縮小方向へのbrkが成功するけどSysV系は失敗する
等の場合だと思うんだけどね。
WindowsならVirtualAllocの動作とか。

OSから得たメモリをどう扱うか(返すか返さないか)を
OSの差に含めて、Windowsではどうするか？なんて
考えるのはナンセンスだと思うけどな。
だいたい、libcをリンクしない場合の事にも言及しておいて
libcの実装の差をOSの差のように言うのは矛盾してるよ。

ごめん、質問に答えてないや。
コンパイラの件について、「どうなのかね？」とは、
単に、「コンパイラとは関係無い」に対して、
リンカまで含めた広義の「コンパイラ」なら関係あるんじゃないか？ってこと。

>>165
マジレス

リンカまで含めた広義の「コンパイラ」

という捉え方があるとは知らなかった。
古い人間でｽﾏｿ
最近はそういうのか。。

ほんとゴメン

ああ ごめん >>161 はそういう意味だったのね。
malloc/free の振る舞いは直接ＯＳの差によるものではないね。
それでもＯＳのメモリ管理の挙動に差はあるけど。

>>162 の回答は >>161の日本語がちょっとわからなかっただけ。
でも >>108 読み直しても、充分そう読めない？
ＯＳについては「系」と書いているし、malloc/free の振る舞いに
関しては全部 libxxx と結びつけて書いてるから、知っている
人に対してはそういう誤解が生じる余地は無いと思ってるんだが。

わからない人には案の定的外れな返答があったので指摘したら
「煽りでしたすみません」となってたみたいだけど。

では。

>「煽りでしたすみません」となってたみたいだけど。
本気にするなよ。それは偽物なんだから。

どーでもいいや

疑問なんだけど、144-149辺りで
「具体的な内容がない」とガキみたいに煽っていたのはなぜだろう。
もしかして、「自分は>>20でUnixの実装を具体的に書いたのに、
誰もWindowsでの実装を具体的に書かない/自分の質問に答えない」
といいたかったのかな？
もしそうなら、>>20や>>22に対する回答は>>138が適切かもしれない。
そう、OSとライブラリを(切り分けが重要なのに)混同しているからだ。
成り行きでDelphiの事例が出て、その周辺を読んでも
「開発環境により異なる」と理解できなかったとしたら、更にね。
そもそも、他の人は「OSの違い」に「ライブラリの違い」は含めないから、
「(malloc/freeは)Windowsではどうなのか」などという考え方はしない。
「Delphiでは」「VC++では」と考える。
OSとライブラリを分けて考えている人からみれば、質問の意味を把握できず
「何訳わかんねー事聞いてんだコイツ」というのが普通の反応だろう。
だからといって、>>20や>>22が「標準ライブラリはどういう実装に
なっているのか？」という質問とは受け取りにくい。
また、ライブラリは(OSではなく)開発環境により異なるという事は
皆知っているから、具体的な回答がなくて当然。
わかっているとは思うけど、Windowsに「標準ライブラリ」は
存在しないから、「標準的な実装」も存在しない。
基本的に処理系付属のライブラリをリンクする事になる。
アプリケーションの動作は、そのライブラリの仕様に従う。
それは前出のDelphiの仕様でり、VC++の仕様であり、BCCの仕様であり、
あるいはJVMの仕様である。
これが望んだ「具体的な内容」が出ない理由でもある。
※もし、煽りの理由が他にあったらすまんね。

１つお詫び。
「コンパイラ」に言及したのは>>100が最初だった。
そして、それに対する反論として「malloc/freeとコンパイラは関係ない」と
答えていた事に、今気がついた。
100もOS/ライブラリ/コンパイラの切り分けができていない。
この場合は、「UNIXの標準ライブラリはプロセスを終了しないと
取得したメモリを解放しない実装が多いが、UNIXのOSの仕様とは関係ないし、
Win95やNTとの比較は意味を持たない」が正しいだろう。
コンパイラとライブラリは関係あるべきだが、切り離す事も出来るから、
「malloc/freeとコンパイラは関係ない」というのはその通りだった。
でも、100を例に出すまでもなく、コンパイラ＝開発環境と捉える人は多い。
また、開発環境にはライブラリを含めて考えるのが普通。
(もちろん、クラスライブラリも)
それに、リンクの過程まで含めてコンパイルと呼ぶ事は
いくらでもあると思うが、違うかな？
まあ、「コンパイラ」でないのは確かだし、この場合には当てはまらない。
ここは俺の言い掛かりに近かった。ごめん。

以上で、俺からはこれでお終い。

>>171 横レスでｽﾏﾘだが、ちょっと忠告。
170でどうでもいいと書いてしまったが 171を読んで気になったことがあった。
１７１が問題にしている事は単なる揚げ足とり。問題はmalloc / free の挙動
について知っておくべきことのはず。揚げ足とりもいいけど大事なのは実際に
ナニが起こって、どうなるかということ。それについて具体的に解説されて
いることが大事であり２０以下が唯一の説明だ。

>>171 「何訳わかんねー事聞いてんだコイツ」というのが普通の反応
とは到底思えない。文面からはっきりわかるのは ２０の説明がわかっていたのは
>>157 だけ。ROMは除く。

ねかまなどは論外としても >>47 >>100 >>121 >>156 >>161 >>164 >>171 は
殆ど同じレベルの理解度の人間だということがスグわかる。 >>157-158 の懇切
丁寧な解説がまだ理解できてないとしか考えられない。もう１度読んだほうが良い。

私や157のように２０の解説がわかるものにとっては、>>171 の書いてることは単に
どっかのレスを論破されたことで主旨を捻じ曲げて絡んでいるだけにしか見えない。
全部でないまでも、上に挙げている >>47 ... >>171 の殆どは >>47 の書きこみ。
図星ダロウ。手に取るようにわかる。

さらに付け足しておくと、前スレのどこかでも指摘があったが、
>>171 「リンクの過程まで含めてコンパイルと呼ぶ事はいくらでもあると思うが」
これは無いってば。 それこそわかってないことの証明だし、だからこそ余計に
発言に真実味がなくなってる。そういう行為のことはUNIXだろうがWindowsだろうが
「ビルド」だ。百歩譲って make だ。>>107 の後半は独り善がりな理解だと
いわれてもしょうがない。

○ >>171
× >>107

>>172
うっさいなあ・・・
アンタがわかってるってことはよくわかったから sageろよ ｳﾞｧｶ

ごめんよ。用語の使い方は俺の方を訂正する。＜コンパイル
元々、108で出た言葉が100への返答だと気がつかなかったから。

俺の番号に一貫性がないのがいけないんだけど、
＞>>171 「何訳わかんねー事聞いてんだコイツ」というのが普通の反応
＞とは到底思えない。文面からはっきりわかるのは ２０の説明がわかっていたのは
＞>>157 だけ。ROMは除く。
157も171も両方俺だ。

＞ねかまなどは論外としても >>47 >>100 >>121 >>156 >>161 >>164 >>171 は
＞殆ど同じレベルの理解度の人間だということがスグわかる。 >>157-158 の懇切
161も164も157-158も俺だ。
157-158を書いて、読みなおして、20と22に疑問を持ったから、161を書いた。
最初に読んだ時、108を正確に理解していたと思うが、20と22の
「(Unixでは)ライブラリの説明をしながら(Windowsでは)OSの動作を聞く」
と感じられ、
「もしかしてOSとライブラリの切り分けが出来ていないのかも」と161を書いた。

それと、47は俺ではない。
俺はこのスレの中盤以降しかレスして無いし、157-158にレス番が
挙がっているのも全て俺ではない。

つーことは、やっぱり俺はわかってないまま157−158を書いたのかも。

ま、157を書き始めた理由が煽りにむかついただから、あら探しもするさ。
でも、また誤解されそうなところを訂正ね。

×元々、108で出た言葉が100への返答だと気がつかなかったから。
○元々、108で出たコンパイルという言葉が
　100への返答だと気がつかなかったのが、引っかかった理由だから。

×最初に読んだ時、108を正確に理解していたと思うが、
○最初に読んだ時は、108の言いたい通りに(正直に)に俺も理解したが、

×「もしかしてOSとライブラリの切り分けが出来ていないのかも」と161を書いた。
○20と22を読んだ後に108を読んで、「強引に読めば、108でもOSとライブラリの
　切り分けをしていないとも受け取れる」と疑問に思い、161を書いた。

＞私や157のように２０の解説がわかるものにとっては、>>171 の書いてることは単に
＞どっかのレスを論破されたことで主旨を捻じ曲げて絡んでいるだけにしか見えない。
論破されたつもりはないが、煽りにむかついてたから
趣旨を捻じ曲げて絡んだのは事実かもね。157=171だけど。

＞全部でないまでも、上に挙げている >>47 ... >>171 の殆どは >>47 の書きこみ。
＞図星ダロウ。手に取るようにわかる。
手にとってくれてありがとうよ。またむかついちゃったよ。

なんでアタシは論外なのよ。
しつれいしちゃうわね。

・・などとまたネタで返してしまったが
やっぱし気になるのでちょっとまじめに書き込むけど
「わかってないやつに話してもしょうがない、
　わかってる奴はわかってるんだから」
て風潮はやめような。
それだったら、そもそもこのネタで話す意味ないだろ？
スレッド批評も結構だが、この一連の書き込みは尋常でないな。
ここまで空気が悪くなってしまうのはマジで少し残念だ。

ま、一通りでたから話すこともないんでしょ。

>>179
解ってないやつの態度次第なんじゃない?
ｼﾞｮｰｼｷ

（・∀・）（・∀・）（・∀・）

>>179
てめーがいなけりゃ、もう少し良い空気だったろーよ。

>>183
なあ。マジでそう思うよ。 ねかまだけじゃないけど。
２ｃｈだから煽るなとかネタするなとか言わないしさ、
間違った指摘されても別にかまわんけど、
あきらかにわかってないやつに
「本当に理解してる人間はもっと要領よく整合性のある説明ができます」
なんていわれるのは許せないね。
だったらオマエしろよ！って感じ。
おれはもっともわかりやすい講義を行っているわけじゃない。
相手のレベル見ながら、それなりの抽象度で書いているのに、
自分はただ突っ込みだけいれ、しかもあきらかに間違った認識でも
あるのに、断定的に理解度について見当違いなことを言う。クソガキめが。

さらに経験から説明した事柄に対して
「適当に検索エンジンで検索して、文章をつぎはぎして張ったりかます」
という煽りはまじヤルキ無くすわ。
はっきりいって、本でもＷＥＢでも、このレベルの実際的な実装の
違いでさえ載ってないよ。俺の知る限りでは。実際に動作を試して
みたやつか、ソース読んだヤツしか知らないはず。
たとえば、brk, sbrkの挙動にしたって、上で書いたほど単純じゃない。
実装の方法にもバリエーションがさらにあるし、挙動のスレッショルドや
チャンクサイズにもまだ触れてない。
引用元があるというのなら、オマエ貼ってみろっていうんだ。
少し難しいことを書いてると、すぐにコピペだと思うやつ。
ｳﾞｧｶそのものだ。他人は自分と同じだと思ってやがる。

ねかまのいうことはわかる、排他的なものいいは良くない、そのとおりだと
思うが、オレはそんなことを一度もしてない。 ただ>>121のような失礼な
やつは絶対に許さない。それだけだ。

「exit() 直前の free() は不要である。」というのは一致した意見のようだけ
ど、それでも free() をした方が好ましいと考えて、積極的に free() したり、
コメントを書くいる人はいるんですか？

まだ収束する気配ないよ．．．>malloc and free
「電子のお針箱」は前回思いっきりたたかれたのにまた出てくるし
また、数ヶ月続くのかなぁ

ひさびさに上がってるね。
>>184
> 「適当に検索エンジンで検索して、文章をつぎはぎして張ったりかます」
> という煽りはまじヤルキ無くすわ。

これは、私も過去何回か言われたことがありますが、そんなこと言う奴は、
・自分にはそれを読み下すだけの知識がない。
・自分ではそのような文章を書けるだけの技量がない。
・さらに、そのような文章を他人が書けるという想像も出来ない。
・くやしいので、とりあえず煽っとく。

といった感じだと思いますね。

ここでHeapというものについて考えて見ませんか？
Heapが何であるかということについては、
「二本目のスタック」という言葉以外、
適切な説明はないと（自分では）思います。
さて、あなたはexitの前にsetjmpや
例外スタックの後始末をしますか？
常にmainで終了するってことが可能
だと思いますか？

>>188
> Heapが何であるか
(多くの実装で)メモリブロックを取得する場所じゃないかな？

> 「二本目のスタック」
スタックだったらなんでメモリの断片化が起こるの？

>あなたはexitの前にsetjmpや例外スタックの後始末をしますか？
exit自体あまり使わなかったりして．．．

>スタックだったらなんでメモリの断片化が起こるの？
ブレークポイントをスタックポインタとみなせばそう。
mallocはランタイム環境とライブラリの問題だから、
OSから見るとたった一つのセグメントの断片化なんて
起こり得ないでしょ?
UNIXのメモリーモデルからかけ離れてしまったら、
malloc/freeという名前は使うべきでないです(と思う)。
別の名前を使うべき。

>>188
>常にmainで終了するってことが可能
>だと思いますか？

じっくり考えたわけではないので、自信無いですが、
コンパイラ次第かな〜？要は使ったレジスタを親から
もらった状態に戻してから、親に戻ればOKってな具合？
したがってコンパイラを使う言語の場合はメモリの問題
とはちと違うと。

fj.comp.lang.cって、なんか言い争い多いね。

去年の年末くらいにも、
標準ライブラリの書き換えでぐちゃぐちゃ言ってなかった？

もうfj.comp.lang.cは見るのやめて、comp.lang.cに切り替えました。
英語の勉強にもなって良いです。

_heapmin()使ってる人いますか?

>188
longjmp使えば、楽勝でしょう。

割れたチョコレートを
「湯せんするからそのまま返してくれていいよ」
というおなごに、
一所懸命四角に繋ぎ合わせて返す
さえないおとこ。

sage

おことがひとりならいいけど、100人もいた。
すぐ割れるチョコをゆせんしまくり。
仕事のトロイ八方美人。

漏れの fj.comp.lang.c の malloc/free 総評。

「とりあえず Sugiyama Yoshimi は引っ込んでろ」

去年のスレでのシロートに毛の生えたご意見はもうたくさん。
（実際プログラマ歴２・３ヶ月って感じだった）

難しいことは、プログラム板の麻衣ちゃんズに聞けば
やさしく教えてもらえるっす。

haa... C ha rekishi ga nagaikara
damedame yaroumo kokomade kichatterunoka...

about this Newsgroup (このニュースグループの使い方)[20010216]
頭のおかしい人の相手をしてはいけません。それは相手の思うツボです。

↑japanに流れているこれってfjには流れないの?

この議論さ、ホント見てると頭いたくなるんだ。

俺はゲームプログラマーなんでmallocもfreeも自前だ。
クラス毎に最適化したヒープルーチン組んだりもする。
そんな環境依存するもの議論する価値ないだろ。

素人が誤解産むだけなんだからちゃんとfreeしとけよ。
ってゆーか、そーゆー対象性の無いプログラム書いてる奴がC++使い出すとハマルだろ。
一人で作るならともかく、多人数のプロジェクトになった時の事考えろよ。

生存時間の少ないお手軽プログラムしか組んでないから
OSに後始末させるなんて寝ぼけた事言い出すんだよな。

あとexitとかでぽんぽんプログラム終了するなよ。
設計が悪いだけじゃん。

最新のOh!Xで「exitの前はfree 要りません」なんて無責任な記事書いた奴。
ニュースグループなんぞに感化されるな。Oh!Xのレベル低下も嘆かわしいな。

>そんな環境依存するもの議論する価値ないだろ。
といいながら、
>素人が誤解産むだけなんだからちゃんとfreeしとけよ。
しっかり、議論を始めてるあたりが、ホント見てると頭いたくなるな。
たぶん脳味噌腐りはじめてる。

>そーゆー対象性の無いプログラム
誤字も痛いし、
> exitとかでぽんぽんプログラム終了するなよ。
これはスレとなんの関係もない。

鶴田とかいうヤツ、uzeeeeeeeeeeeeeeeeeeeeee!

どちらにしろ、ケースバイケースで考えることを忘れた、
頭の硬い人にはなりたくないです。

嫌味、皮肉、あてこすり、見下し。
あーやだやだ。
あれ読むと、リコーとかPFUとかが嫌いになりませんか？(ﾜﾗ

なんで? 逆では?

それよりも>>203のおかげでOh!Xが未だに存在することが
判明しました。インターネットはまったく凄い！

> 嫌味、皮肉、あてこすり、見下し。
あそこはコテハンが多い2chなので正常な神経を持つ人が見るものではありません。

まだ、まともな神経を持っている人はyahooに逝って下さい。

>>208
いや、逆ではない。
リコーとかPFUのヤツとかその他の電波なヤツ、ウザすぎ。

>「exit 前で freeする必要はあるか？」
>と言う問いに対しては、
>
> ある環境や条件ではfreeが要るかもしれない。しかし、全く要ら
> ない環境や条件も存在する。
>
>従って、
>
>「exit前でfreeが必ず要るというわけではない」
>
>すなわち
>
>「exit前でfreeする必要はない」
>
>と言えるのです。

と言えるわきゃねーだろ(ﾜﾗ

・ANSI-Cで、
・寿命が短い(GUIでない)、
・C++ではなくCのプログラムで、
・(OSによってはありうる)他の開放しなければならない資源をアロ
ケートしていない

というごく限られた条件の中で、

mallocでdefault heapから割り当てられたメモリブロックをfree
しないでexit()して良いし、場合によってはパフォーマンスがあがる

と言っているだけなのに、なんで、他の一般化された場合に対しても、
それを当てはめられたと思い込んで、いつまでも反論し続けている
のかわからん。

なんでC++ではとか関係無い事を言い出すんでしょうか。

> いつまでも反論し続けているのかわからん。
変な宗教（mallocしたら絶対にfreeしなきゃいけない教）に入信してるから

>>213
>・ANSI-Cで、
>・寿命が短い(GUIでない)、
>・C++ではなくCのプログラムで、
>・(OSによってはありうる)他の開放しなければならない資源をアロ
ケートしていない
という環境が、彼らの世界の全てだから、そこに拘泥しているのでは？

デムパっぽいのはお針箱、シロート丸出しなのが Sugihara。

全体的に free fundamentalist の旗色が悪いと思うが。
特に Sugihara はスタックと auto 変数の関係も
本当に把握してるかどうかすら怪しいゾ。（Obstack の事じゃなくて）

news:[email protected]
に対する彼のフォロー
news:[email protected]
を読んだかぎりでは相当怪しい。
news:[email protected]
news:[email protected]
で追求されても知らんふりだしな。

>>213 が書いたとおり、条件をはっきり出した上での
「free は不要」なのにちゃんと読んでない人多すぎ。
仕様書もその調子でないことを祈る。

>>215
??
あなた箱さんですか?

>>217
> あなた箱さんですか?
漏れもそうオモタ（藁

> デムパっぽいのはお針箱、シロート丸出しなのが Sugihara。
に対して、
> 嫌味、皮肉、あてこすり、見下し。
を駆使する面々。

俺は後者のほうが嫌い。

好き嫌いで論理の破綻が逆転するわけじゃない

ANSI-C においても exit() 直前の free() をした方が好ましいと考える人はい
るのですか？

てっきり、自説の恥ずかしさに気がついて、
サイバー自殺したと思っていたのに…

１ヶ月ぶりに見てみた。

>>216
素人かどうかはわからんが、経験が少ないのに
経験豊富っぽく見せようとしてボロ出してる感じだな。

--------------- 引用開始 ---------------
> それはそうですけど、それをいうならshortもlongも同
> じでしょう?

short ・・・　2byte
long ・・・ 4byte

以外の場合があるということでしょうか。
--------------- 引用終了 ---------------

こんなこと言ってるし(´д｀）

>>203
うーん。その論旨はまさに電子氏にクリソツに思えるのだが？
素人の誤解を数に入れはじめたら電子氏と一緒にドツボにハマルだけ。

OhXっすか。もとよりレベル低いでしょ(笑)。
大昔、あれに、Cのプロトタイプ宣言を「余計なお世話」とか
書いてる記事があったんで、笑ったもんだった。

>>224
同意できるが、ただ203の人はどうしようもないプログラマーに嫌という
ほど痛い目にあってるんじゃないかと同情する。UNIXを知らなすぎるのは
問題だが。デーモンを自分で書いたことはないんだろうし、Apacheのソース
を読んだこともないんだろう。

とりあえず /usr/proc/bin/pmap -xl でも実行してみりゃわかりよいかも

ネタとしか思えない箱氏の蒸し返し発言が始まったよ。
同じこと何回も何回も何回も何回も何回も何回も。
一つの事にこだわると他の事を学べないのかこの人は！

元々は「そういう時もあるんですね」で済む程度の内容なのにね。
どうせcでmallocを使って、freeのコストが大きいコードは書いて
いないのだろうから、気にしなきゃいいのに。

>>228
自分で判断できないから、他人に同意を求めようとしているんだけど
煽られているうちに目的を見失ってしまった様子。

>>229
仔細に内容を読んでるわけじゃないけど、職業プログラマの
システム開発プロセスという観点から見たら、箱氏の勢力(?)
のほうがよっぽどましに見える。技術力はともかく。

以前「開発現場のお寒い状況」云々の話をしてたが、あれっぽっち
の会話で「開発現場」を規定してもらっちゃ困るね。

プログラマが賢くちゃいけない、みたいな雰囲気です。
反知性主義的というか。
典型的なスウェットハウスじゃねーの？ < 箱氏の言う「開発現場」とやら

スウェットハウスってなんですか？
たこ部屋とかそういうニュアンスですか？

ところで、free standing environment を
無視したがる人が多いのはなぜ？

>>233
別に無視してるわけじゃなくて、知らないだけでは？

>>233 >>234
特定の環境依存の話をしても無意味だからでは？

malloc, free, exit の話に限ればそうだよね。

でも、それだけに限らない人がいるように思える。
組み込み用の C は ANSI-C じゃない、とまで
言い切った人もいたよね。

つーか、malloc, free, exit の話題だよね? (藁
それ以外で >> 236 のように言い切った人は記憶にないなあ

箱氏、このところ木曜日になると現れるな。
次回のＸデーは２４日か？

この予言が当たったらこの私を崇めるように。。。

ただ今、１７日（木曜）朝７：３０。
箱氏の投稿４件発見！へへ〜〜〜っ（ひれ伏し） ＞ 238

カキコしてから気づいたが238って俺のカキコの
ほんの直前のものだったんだね。でも自作自演じゃないぞ！

まだ終わってねーの？
もうfj.comp.lang.cとっくの昔に巡回からはずしたからどうでもいいけど(笑)

>>231
同意。

ｆｊより２ちゃんねるのほうがよっぽど質が良い。
大部分が２ｃｈに流れたせいかな？

NEWS の方を読んでないから知らないけど、小さなプログラムを後々大きなプログラムのライブラリとして使うようなとき、
関数の対称性が取れてないと苦労するから、悪癖つけるだけの free 不要論は必要ないと思うのだけど。

きっと、これも想定されないケースなんだろうな(笑)

news読んでからなら、そんな事きっと書かないよ。

>>244
free() が必要ならすればいいだけの話。俺は fj の free 不要派の意見に
賛成だ。

>>244
> NEWS の方を読んでないから知らないけど、
要約すると「ANSI-Cならは、exit()前のfree()は不要」だ。

> 小さなプログラムを後々大きなプログラムのライブラリとして使うようなとき、
> 関数の対称性が取れてないと苦労するから、
お前、ライブラリにexit()付けたままにするのか？
exit()とreturnって意味が違う事は知ってるよね？

> 悪癖つけるだけの free 不要論は必要ないと思うのだけど。
読んでない議論にしゃしゃり出たり、
何も考えずに関数を流用しようとするお前の方が必要ない。

>不要
ﾋﾟｸｯ(ﾜﾗ

>>247
>要約すると「ANSI-Cならは、exit()前のfree()は不要」だ。
それ以外のfree()が圧倒的大多数を占めているため
どうでもいい主張ですね。つか覚えるだけ無駄な感じ。
なにかメリットあるの？

>>249
> どうでもいい主張ですね。つか覚えるだけ無駄な感じ。
> なにかメリットあるの？
プログラムと同じ寿命を持つデータ構造をわざわざ解体する必要が無い。

>>250
その通り。malloc は必要でも free が必要ない、っていうか free する
と手間もかかり性能も深刻なまでに劣化する、というケースだってある
だろう。

箱や馬鹿 Sugihara が言っている意味での「原則 free」ではこういった
ケースには対処できないのだよ。太田@Ricoh さんや片山@PFU さんの主張
をもっとよく吟味しよう。

結論：
片山＠PFUはウザイ。

一般的に言って、自分の間違いを指摘されて、
ウザイで済ませるやつはクソだね。

>>252
おまえがな。

ちなみに Warez 御用達 GCA を作ったしんいちつるたは俺も宇材
と思う。

>その通り。malloc は必要でも free が必要ない、っていうか free する
>と手間もかかり性能も深刻なまでに劣化する、というケースだってある
>だろう。
コンシューマのゲーム開発ではヒープの断片化が非常に大きな問題になる。
しかし「freeしない」という回避策はありえない。もっとべつの方法を取る。
議論のためだけに現実にやってもいない方法論を振りかざすのはやめてくれ。

>>255
> しかし「freeしない」という回避策はありえない。もっとべつの方法を取る。
誰が全くfreeしないと言っている？
不要なfreeはしないだけ。必要なfreeはする。

> 議論のためだけに現実にやってもいない方法論を振りかざすのはやめてくれ。
シッタカしたいためだけに現実に誰も言ってない事に反論するのはやめてくれ。

あいつら所詮Cどまりの厨房。
これ以上糞コードを
ばら撒かないことを祈るのみ。

>> 255
反「原則free」派は当然そんなこと折込済みで言ってるんだよ。
むしろ「原則free」派にこそ、フラグメンテーションの問題をちゃんと考えて欲しいね。
「freeさえしてれば、長時間稼動するサーバやライブラリの設計変更でも安心」などと
いう間抜けな考えを広めないためにもね。

つまり動的static変数みたいな使い方？
いわれてみればこういう使い方したいときあるなぁ

ここがドカタCプログラマのすくつでちゅか〜

>>253-254
俺がどうなのかはさておいて、絶対評価すれば片山＠PFUと鶴田はウザいぞ。
具体的に言えば、彼らは、粘着質で、社会的常識に欠け、コミュニケーション
能力に著しく欠けてる。

どんなに彼らがスゴい能力を持っているとしても、俺は人間的に
認めることは出来ないな。

箱氏の発言。

<[email protected]>

> とりあえず一点だけ、確認させてください。
>
>Shin-ichi TSURUTA <[email protected]> wrote in message
>news:[email protected]...
>
>> > > 何れ決定しなければいけないことを、コーディング前の設計時に決
>> > > 定しておくことは高コストではありません。後でお寒い状況になる
>> > > 可能性を考えれば、遥かに低コストでしょう。
>> > 貴方は以前...
>> > Shin-ichi TSURUTA <[email protected]> wrote:
>> > > freeやmallocを書き始めてから、検討するのではないのです。設計
>> > > 段階ですべて決める。
>> > と、設計段階で全ての free()/malloc() を決めると書いてますよね。「つまり
>> > コーディング前に全ての free()/malloc() までが決まっているんですよね。
>>
>> 「各モジュールで必要とされるリソースを、どのように利用し解放
>> するorしないか」をです。
>
> 私は、「つまりコーディング前に全ての free()/malloc() までが決まっているん
>ですよね。」と聞いているんですよ。リソースについてなんて書いて頂かなくても結
>構です。(話が発散するだけですからね。それともそうしたいの ?) とにかく、貴方
>の言う「きちんとした設計」をした時は「コーディング前に全ての
>free()/malloc() が決まっているのですか ?」に対して、Yes/No でお答えくださ
>い。

さて、鶴田はなんと答えるか？

俺は口をつぐむに10000ペリカ。
そういう奴なんだよ、鶴田って。

片山氏の発言（箱氏へのフォロー）

<[email protected]>

>それはともかく、まともに設計できない者に設計をさせることが、どれ
>だけ無駄なコストを発生させているかを認識していないようですね。
>
>教育などは全く考えていないのでしょうね。或は、
>
> 教育して技術レベルが上がるとスピンアウトされるから、思考停止
> させて、いつまでもレベルが低いままにさせておこう
>
>と考えているのかもしれませんね。
>
>＃そういう環境なら、最初からそうだと書いてくれれば、むだな議論を
>＃しなくて済んだのに

これがまともな社会人の言うことかいな。
粘着もたいがいにして欲しいね。

>>263
付け加えると、片山氏は箱氏あるいは箱氏が所属するチームないしは会社を
「設計もろくに出来ない低能力技術者集団」と決め付けており、
その妄想を根拠とした発言を数ヶ月に渡って繰り返してる。

これをウザいと言わずしてなんと言おうか。

更に付け加えると、俺自信は粘着質で、ウザい、コミュニケーション不全な
社会人失格人間だよ。俺を貶めても何にもならないよ（ｗ

変に鶴田氏や片山氏を持ち上げる、あるいはすごいと感じてしまう
厨房君は目を覚ませよ。

ただの自動変数でも、
OSにまかせておけば実質的にmalloc/free程度の制御がはいりますよ。
（copy-on-writeとページングね）
仕様上、最大長が決まっているのであれば大きな配列を自動変数でとっても、
mallocで動的に取っても、結果的にはそんなにかわんない。
最大長が決まってなければ最大ファイルサイズ（2GBとか）くらいにとってみるか。
メモリの話はOSもからめて考えないと、不毛な議論かもね。

鶴田の発言（と俺のコメント）。

<[email protected]>

>何れ決定しなければいけないことを、コーディング前の設計時に決
>定しておくことは高コストではありません。後でお寒い状況になる
>可能性を考えれば、遥かに低コストでしょう。

後から決定すればよいことを、先に決めることによるコストには
気づいてないようです。

>どうやら、私が世間知らずだったようです。申し訳ありません。
>設計もできないのに飯が食える人がいる理由がよくわかりました。

氏ね。

さて、鶴田は
<[email protected]>

>当然のことです。それで矛先をそらしたつもりでしょうか(藁)。

と書いているので２ちゃんねらーだと思うが、見てたら何か言え（藁

>>261
> 俺がどうなのかはさておいて、絶対評価すれば片山＠PFUと鶴田はウザいぞ。
> 具体的に言えば、彼らは、粘着質で、社会的常識に欠け、コミュニケーション
> 能力に著しく欠けてる。
両者がウザイのには同意。あと箱とSugiharaもウザイリストにaddしといてくれ。
箱がいなければ前回といい今回といいこんな長大なスレッドにはならなかっただろう。
さらにSugiharaは技術力も著しく欠けてる。

2ch風にいえば「ドッチモナー」かな？

>>269
うむ、箱氏もウザいのは同意。
Sugihara氏は論外。

最近参戦してきた奴もウザいね。

>>258
全く同意見。

> 最近参戦してきた奴も

参戦したいやつがいるのか？
よっぽどのヒマ人だね

>>271
>>>258
>全く同意見。

いや、だからさ、フラグメンテーションがいつも問題になるような
システムばかりを作っている人たちは、フラグメンテーションの
問題を考慮した設計をしなけりゃならないだろうけど、そうじゃ
ないシステムを作ってる人たちも大勢いるんだよ。
何ヶ月もノンストップのサーバアプリでね。

自分達が見えてることだけを基準に物を言わないこと。
自分達がいつでもフラグメンテーションの問題を考えてるからと
いって、考えてない設計を「間抜けな設計」「間抜けな考え」
なんて評さないでくれ。

>>273
> そうじゃ
> ないシステムを作ってる人たちも大勢いるんだよ。
> 何ヶ月もノンストップのサーバアプリでね。
あっそう。だから？
そんなことを告白してなにが言いたいの？

> 自分達が見えてることだけを基準に物を言わないこと。
オマエモナー

> 考えてない設計を「間抜けな設計」「間抜けな考え」
> なんて評さないでくれ。
アホをアホと言わないでっていうお願い？
僕をバカにしないでっていう懇願？

# なにがいいたいのかさっぱりわからん

>>274
>> 自分達が見えてることだけを基準に物を言わないこと。
>>オマエモナー

論理的思考が出来ないみたいだね。

># なにがいいたいのかさっぱりわからん

わからないなら、無理に発言しなくてもいいよ。

>>274
>アホをアホと言わないでっていうお願い？
>僕をバカにしないでっていう懇願？

この文書き終えた後に、小さくガッツポーズ取ったんだろうな（藁

先週末から今週にかけて、レベルの低い厨房が跋扈し始めたな。

>>273
>自分達が見えてることだけを基準に物を言わないこと。

オマエモナーって言わせたいのか。(ﾌﾟ

>>275
> 論理的思考が出来ないみたいだね。
論理的発言をしてない奴に言ってくれ。

例えば>>273みたいに
> そうじゃないシステムを作ってる人たちも大勢いるんだよ。
多数決で同意を求めようとしたり、

> 考えてない設計を「間抜けな設計」「間抜けな考え」なんて評さないでくれ。
感情に訴えかけたりする奴。

>>276
> この文書き終えた後に、小さくガッツポーズ取ったんだろうな（藁
そんなに面白かった？まだまだＴ氏の域には達していない
（Ｔ田の方が適切なのか？）

>>277
> 先週末から今週にかけて、レベルの低い厨房が跋扈し始めたな。
そうだね、そういう奴って感想しか言えなんだよな。>>277みたいに

>>274
アホクサ。

>>279
>そうだね、そういう奴って感想しか言えなんだよな。>>277みたいに

お前は感想すら言ってないがな（藁

>>273
いや、だからさ、自分達の開発の前提条件とか要求条件から判断して「必ずfree
する」とか「フラグメンテーションの問題は考慮する必要なし」というのは
ぜーんぜん問題ないんだよ。

でも、そこで重要なのは「必ずfreeする」という結論じゃなくて、それが
成り立つ前提条件とか通用範囲なのさ。

俺が間抜けと言ってるのは、そういう前提をろくに意識せずに「freeしてるから
安心安心」などと安直に考えてしまうことだよ(あんたがそうだと言ってるんじゃ
ないからね)。

いくら今の自分の範囲でその前提が99.9%成り立っているとしても、一般的な
malloc/free の使い方の話で安直に「原則free」などと言う奴は、やっぱり
前提条件に対する意識が低すぎると思うね。

悪い、俺「跋扈」って読めねえ（藁
俺ってレベルの低い厨房以下？

258、あなたいい人だよ。心が洗われたね。

>いや、だからさ、自分達の開発の前提条件とか要求条件から判断して「必ずfree
>する」とか「フラグメンテーションの問題は考慮する必要なし」というのは
>ぜーんぜん問題ないんだよ。

同意。こういう柔軟な考えが出来ない（ように見える）奴が多いから、
いらつくんだよね。

>跋扈
ばっこ。跳梁跋扈（ちょうりょうばっこ）とか使う。知らなくても問題なし。
ホラー系の単語？だから（ｗ

>>284
わたくしも同意するであります。

>>283
> いくら今の自分の範囲でその前提が99.9%成り立っているとしても、一般的な
> malloc/free の使い方の話で安直に「原則free」などと言う奴は、やっぱり
> 前提条件に対する意識が低すぎると思うね。
箱に対して言ってるだろ。
奴は自分の範囲での前提条件を一般的な前提条件に摩り替えようとしてる。

>>284
> 同意。こういう柔軟な考えが出来ない（ように見える）奴が多いから、
> いらつくんだよね。
頑なに原則freeと唱えてるほうが柔軟な考えではないと思うが？

所詮、何をどう言ってもタコは平気で必要なfreeをしなかったり、
やってはいけないfreeをするんだから。

>>286
おまえ馬鹿だろ。
つーか、日本語読めないんだろ。

無理して発言する必要はねーって言っただろうが。
黙りやがれ、この厨房が。

>>287
> おまえ馬鹿だろ。
> つーか、日本語読めないんだろ。
呼ばれもしないのにのこのこやってきて
無理してくだらない煽りをする>>286は馬鹿だろ？
つーか羞恥心がないんだろ？

> 無理して発言する必要はねーって言っただろうが。
> 黙りやがれ、この厨房が。
俺に絡んでるけどなんか気に触った事でも言った？
そういう論理的でない感情の吐露はママの胸の中で言ってくれ。

# もっと酷く煽るぞ

集合を知らないと、否定を肯定と取れてしまうんですね。

>>288
おまえ、誰かと誰かを混同してるみたいだけど、俺が言いたいのは

バカはしゃべるな

だ。それもわからんバカなのか。

何か言いたいなら、内容のあることをしゃべれ。

>>290
> バカはしゃべるな
じゃあなんでお前がだまらないの？
それもわからんバカなのか。

> 何か言いたいなら、内容のあることをしゃべれ。
って何で内容のないことをしゃべることができるの？
そういう発言が矛盾してることに気づかないバカの分際で
偉そう人様に意見を言うのは１００年早い。

# でもわかんないんだろうなー「バカ」だから。

>>291
おまえこのスレで一体何を語ったんだ？
何番の発言？

>>291
おまえ、他のスレも荒らしてるだろ。
いいかげんヤメレ。

>>292
> おまえこのスレで一体何を語ったんだ？
>>273はワケワカランって語った。
だいたいfree on exitとフラグメントは別問題だろ？
Ｏ田氏の言葉を借りて言えば
「原則freeしてフラグメントが発生しなければ
　free on exitしてもフラグメントが発生しないだろう」

>>293
> 他のスレも荒らしてるだろ。
誓っていうがここ以外ではこんな挑発的な発言はしていない。
お前の荒らしの定義って何？
荒らしを駆逐する為には荒らしになってもいいの？
そういう無駄な発言が荒しを呼ぶんだよ。
いや、無駄ではないな。俺に突っ込むエサを与えているんだから。
気に入らなかったら無視すりゃいいのに。大人になれよ>>293は。

# それとも、無視できない理由でもあるの？

>>>273はワケワカランって語った。
>だいたいfree on exitとフラグメントは別問題だろ？

へ？そんなことは判ってるよ。
>>273 は>>258に対するレスなんだが。
ちゃんと読めよ。

>誓っていうがここ以外ではこんな挑発的な発言はしていない。

それはすまなかった。謝罪する。

>お前の荒らしの定義って何？

例えば>>274のような煽り発言だ。

>>>273
>> そうじゃ
>> ないシステムを作ってる人たちも大勢いるんだよ。
>> 何ヶ月もノンストップのサーバアプリでね。
>あっそう。だから？
>そんなことを告白してなにが言いたいの？

>>258 -> >>273の流れで、いきなりこんな煽りをするのは、荒らし以外の
なにものでもないだろう。

さぁ、流れもわかったところで、>>258 -> >>273の流れで、
何か意義のあることを言いたいなら言ってくれ。

それから暇があったら、>>282 -> >>286で、もう一度
286の内容を説明してくれよ。

何言ってるかさっぱりわからんぞ。

>>295
> >だいたいfree on exitとフラグメントは別問題だろ？
> へ？そんなことは判ってるよ。
これさえ意見が同じなら別に意見などない。

ただ、残念ながら俺の読解力がないのか書き方が悪いのかわからんが
free on exitとフラグメントは別問題と言っているようには読めなかったし、
>>273 で
> 自分達が見えてることだけを基準に物を言わないこと。
と挑発的な文章に感じたので、煽ったまでだ。（ちなみに258とは別人）

> いきなりこんな煽りをするのは、荒らし以外のなにものでもないだろう。
上記の通り「いきなり」ではない。

>>296
> 何か意義のあることを言いたいなら言ってくれ。
うーん、どうしよう。じゃあ１つ聞いていい？
「長期間稼動するサーバやライブラリでフラグメンテーションを考える必要はあるか？」
俺は考える必要がないと思う。
考えなければならなくなる羽目に陥るのは設計が悪いかOSが悪い。

>>297
> 箱に対して言ってるだろ。
> 奴は自分の範囲での前提条件を一般的な前提条件に摩り替えようとしてる。
これのことか？

これはfj.comp.lang.cで暴れてる電波のお針箱（電子だったっけ？）とかいう奴のこと。
多分258もそいつを想定して言ってると思う。

# カンチガイだったら間抜けだな．．．

おー、なんかみんな楽しそーに煽りまくってるじゃん。俺も混ぜてよ。
馬鹿！ 黙れ！ 厨房！！ 跋扈！！(早速使ってみた)

さて、本題ですが・・・
>>284
俺の文章に同意してくれてるんだけど、一応俺が強調したかったのは、
その次のパラグラフ「それが成り立つ前提条件とか通用範囲が重要」
の方なんで、そこだけよろしく。

要するに「原則freeが適用できる状況」もあれば「原則freeが
適用できない状況」もあるってことさね。それをちゃんと判断してねと。
「反・原則free派」はそれをずっと言い続けてきただけのはずなんだけどね。

>>299
まあ確かにそうなんだけど。でもわざわざ箱氏を引き合いに出さずとも、
前提条件、通用範囲というものに無頓着なのはやっぱ技術者として困るぜ、
と言いたいわけなのさ。

おめーらfjに帰れよ。
ここはfjの厨房どもを晒し者にするスレなんだからさ。

今まで大丈夫だったから大丈夫ってやつだな。

>>298
やっとわかってくれたようで俺はうれしいよ。

>ただ、残念ながら俺の読解力がないのか書き方が悪いのかわからんが
>free on exitとフラグメントは別問題と言っているようには読めなかったし、

あらためて読み返すと、俺も書き方が悪かった。

>>258
>「freeさえしてれば、長時間稼動するサーバやライブラリの設計変更でも安心」
で、「サーバアプリ」「デーモン」に限定した話題と思ってしまった。
だから、free-on-exitもクソもない。exitしないんだから。

>>298
>「長期間稼動するサーバやライブラリでフラグメンテーションを考える必要はあるか？」
>俺は考える必要がないと思う。

>>273でも言ったが、考える必要もある人たちもいれば、必要ない人たちもいる。
あるいは、考える必要のあるシステムもあれば、ないシステムもある。

ちなみに俺がよく作る、UNIXの業務アプリ（デーモン）や、通信系のデーモンだと
考える必要はほとんどない。
もちろん、フラグメンテーションは起こってるんだが、それは問題にならない。

ただ、何度も言うが、それをいつも考えざるを得ない人たちもいるだろうし、
そういう人たちにとっては、
>>258
>むしろ「原則free」派にこそ、フラグメンテーションの問題をちゃんと考えて欲しいね。
>「freeさえしてれば、長時間稼動するサーバやライブラリの設計変更でも安心」などと
>いう間抜けな考えを広めないためにもね。

ということなんだろうと思う。

追記。

たまに、C++なんかで、
「new使ってる奴はクソ」
とか言いたがる奴がいる。operator newを書き換えろ、と言ってるわけだ。

あるいは、
「malloc - freeを何度も繰り返すんじゃねーよ。独自のメモリマネージメント
もできない奴はバカ」
みたいな論調とか。

そんなものは状況次第あって、上のようなことを言い切れるはずが無いんだよね。

ひょっとして258はそんな厨房か、原理主義者かと思ったんで、軽く煽っといた。

もちろん今ではそうではないことはわかってます。

>>300
>要するに「原則freeが適用できる状況」もあれば「原則freeが
>適用できない状況」もあるってことさね。それをちゃんと判断してねと。
>「反・原則free派」はそれをずっと言い続けてきただけのはずなんだけどね。

もちろん同意しているのこの部分ですよ。「柔軟に」ってくだりね。太田氏
にしろ、片山氏にしろ、前田氏にしろこういう主張だと理解しています。

# しかし Sugihara Yoshimi はまじで議論から消えて欲しい。レベル低すぎ。

>>300
> 前提条件、通用範囲というものに無頓着なのはやっぱ技術者として困るぜ、
そうだな、どんな状況でもある一つの手法にしがみつくのは馬鹿の一つ覚えだし、
馬鹿の一つ覚えはコンピュータに任せておけばいい。

>>304 了解
caseで十分なのにジャンプテーブルを使いたがったりする奴とかな、
最近の2chだと「無条件に」VBは糞と言いたがる厨房が多いな。

# しかし、malloc and freeはいつまで続くんだろう．．．

SugiharaはCL.EXEを使っているという意識はないんだろうなぁ。

>>305
了解了解。なら言ってることは同じだね。

>ひょっとして258はそんな厨房か、原理主義者かと思ったんで、軽く煽っといた。

まあ、そう読めるのも当然かな。そういう書き方してるからね（藁

でも、その手の原理主義的発言する奴ってのはたぶん、「本来そうすべきなの
にそうなっていない」誰かの書いたお馬鹿なコードに、さんざん苦しめられた
経験があるからなんだと思うね。

だから、そういうお馬鹿な奴らに、「いざ」というときにそれができる位のスキルは
（最低でも必要性を認識できる程度は）身につけとけよ、と言いたいんだと思うぜ。

>>308
>でも、その手の原理主義的発言する奴ってのはたぶん、「本来そうすべきなの
>にそうなっていない」誰かの書いたお馬鹿なコードに、さんざん苦しめられた
>経験があるからなんだと思うね。

そうなんだろうね。箱も多分そういう意味で被害者なのだろう。

＃Sugihara は別。

>>261-265
あなたが人間的に認めようが否定しようが、技術屋の能力や
議論の中身（論理的・技術的な正しさ）とは何の関係もない。
あなたは世界の中心に位置して論理の正しさを支配する神ではないんだ。
目を覚ませ。

＞更に付け加えると、俺自信は粘着質で、ウザい、コミュニケーション不全な
＞社会人失格人間だよ。俺を貶めても何にもならないよ（ｗ

ここを読むと神ではない事を自覚してるように思えるが、
なおその上で「俺は」認めるとか認めないとか言ってるところを見ると
ただの予防線なんだろうな。粘着質なだけじゃなくセコイね（苦笑）


あそこは fj.comp.lang.c であって fj.life.japan や
fj.soc.* ではないんだよ。（fj.soc.* の悪質さは置いとく）

追加じゃ。
Sugihara はもうどっか行って欲しいな。
闘牛場に紛れ込んだ犬みたいでウゼー。

牛＝お針箱氏、闘牛士＝反原則freeの人、牛にじゃれつく犬＝Sugihara

>>310
あのさ、俺が引用した発言が、君が言う「議論」足りえるとでも言いたいの？

>あなたは世界の中心に位置して論理の正しさを支配する神ではないんだ。

そんなこと言われなくてもわかってる。

>目を覚ませ。

何からさ。

>あそこは fj.comp.lang.c であって fj.life.japan や
>fj.soc.* ではないんだよ。（fj.soc.* の悪質さは置いとく）

fj.com.lang.cだからこそ、片山@PFUや鶴田の発言がウザイって言ってるんだけど。

んで、君は何が言いたいの？
ｻﾊﾟｰﾘわからん。

なまをです。
あれは私の息子です。
ああ見えても素直な子なんですよ。

>>312
> >目を覚ませ。
> 何からさ。

>>265
> 変に鶴田氏や片山氏を持ち上げる、あるいはすごいと感じてしまう
> 厨房君は目を覚ませよ。

などと書いてあるんで夢見てんのはあんたじゃないかと思ってね。
「俺の嫌いな人間と同じ意見を言うやつはみんなそいつの信奉者」
という夢。違うか？

ここのスレ見て話題のニュース購読してみたんですが、
そんなに議論しなくてはいけない内容なのでしょうか？
話の中身以前に議論の目的自体が疑問でしょうがないのですが？

>>315
あそこの人たちはみんな自分の知識をひけらかすのが好きなんだ。
だからくだらない話題でもすぐツッコミたがる。
そしてみんなプライドが高いから、少しでも意見が食い違うと
自分のプライドをかけて、自分の意見が正しいんだ、って議論を始めるの。
議論の目的はプライド。内容に意味はない。

だからアナタの疑問は正しい。
fjの人たちがおかしいの。

ま、あんまり気にしないほうがいいよ。

>>315
でも議論の発端自体はそんなに変じゃなかったんだけどな。
素朴な初心者の質問に答えていただけ。

俺は >>316 の意見には賛成できないけど、でも一部の人間が自分の意見に
凝り固まっちゃって人の意見に聞く耳を持たなくなったのはそうだね。

結論として、あれは技術的な議論から発生した
宗教論争(mallocしたら必ずfreeしなければならない教の)なんだな。

でも、いつのまにか「必ずフリーしろといっているわけではない」に
かわってますよね。だから、もう終わっていいはずなんだけど、箱に
切れちゃった片山に箱が応戦している状態が続いています。

そうだな。片山氏はいつもきちんとした根拠を出して議論する人だから、
それをいくら出しても聞く耳も持たず自論ばっか繰りかえす箱氏に対して
切れてしまうのも無理はない。

この春で2年目になる後輩が簡単なCGIプログラムでexit()前に
free()して、そこでバグ出してはまってた。なんでfree()なんてしてるの？
と言ったらキョトンとしたので、いろいろ教えるのに、fj.comp.lang.cの議論
は役に立ったよ。同僚にITRON経験者もいて、自前で解放してやる
必要があるケースについてもついでに教えることができて良かった。

>319

片山氏もだいぶ頭おかしくなってきてない？

ポインタの比較に関するスレッドの方で、不定になると思うのは規格書の
読み間違いだろうとか言ってたよね。

C FAQ 読めって感じだよ。

>>321
むむ、そんな記事記憶にない。message-ID 教えてちょ。

結論としては、どうすべきなのですか？
free()しないほうがいいのですか？

mallocしたらfreeする。
それができないようなケースでは
（こういうのは全体の割合でみたらレアケース）
malloc/freeの代替案を探す。
そしてもうfj.compには関わるな。

>（こういうのは全体の割合でみたらレアケース）

あほか。なんでそう言い切れるかね。人それぞれ違っていて一般化は
できないって。

もうageるなよ。基地外はfjに帰れ。

>>326
おまえがな。(藁

>>327
チミだと思うが

お約束で
ドッチモナー

>322
今 galaxy で検索したら、リアルタイムで読んだ時と文章がちがうよ。
なんか、いやな気持ちになった。

無能で勤勉なプログラマー
vs
有能で怠惰なプログラマー

軍隊だと、有能で勤勉なのは参謀にして
有能で怠惰なのは隊長にして、
無能で怠惰なのは兵隊にして、
でもって無能で勤勉なやつは害悪もたらすので銃殺にするんだよね。

331さらしage

>>332
確かにバカまるだしですな。

>>331
ってこたぁ、あのスレは
隊長（反原則Free）vs銃殺死体（原則Free）
って事ですかい？

>>314
>などと書いてあるんで夢見てんのはあんたじゃないかと思ってね。
>「俺の嫌いな人間と同じ意見を言うやつはみんなそいつの信奉者」
>という夢。違うか？

あのさー、俺が夢見てようが見てまいが、「片山＠ＰＦＵ、鶴田はウザイ」
ということと関係ないでしょ。

俺は261からの引用で、彼らがfj.comp.lang.cにおいてウザイ発言をしてる
（ほんとは繰りかえしてることまで引用したいんだが。俺は粘着だから（ｗ）
のを示したでしょ。
それに対する絶対評価をして、何か言いたいことがあるなら言え。

夢見てるのはお前じゃ。妄想はやめれ。

>>335
ハァ？なんで“絶対”評価？
反論が怖いからって予防線張って自爆してるよ。

ウザいなんてものは相対評価でしょうが。
１．どの観点から
２．何と比べて
がないと言えないの。
で、何と比べるかって言うと「自分の中の普通の人モデル」となの。

ここで“絶対”なんて言葉が出てくるのは
> 自分が世界の中心にいて…
ってのが当たってるからだろうね。

もう、いいかげん目ぇ覚ませよ（笑）

>>336
つーか、マジ君何がいいたいのかわからんよ。
俺を貶めて悦に入りたいの？
俺が言ってる「絶対評価」は、俺の評価とは別に彼らを評価しろ、っていうことだ。
引用した俺がドキュソかどうかは関係ないっつーこと。

>ウザいなんてものは相対評価でしょうが。

んじゃ、君の言う相対評価でいいよ。
261から引用した彼らの発言をどう思うわけ？

ウザくないよ、まともだよ、彼らは社会人として立派な発言をしてるよ、
って言いたいんだろうなー。

別に君がどう思おうとかまわないけどね。

>もう、いいかげん目ぇ覚ませよ（笑）

なんの説得力も内容もない発言を繰り返しても、俺の考えは変わらないよ。
再度言う。

つーか、マジ君何がいいたいのかわからんよ。
俺を貶めて悦に入りたいの？

> 俺が言ってる「絶対評価」は、俺の評価とは別に
> 彼らを評価しろ、っていうことだ。

あのな、言っとくが国語の勉強は大事だぞ。
既存の言葉を勝手に再定義するなら尚の事だ。
「絶対」という言葉にはそんな意味などない。
せめて「独立評価」ぐらいにしておくべきだったな。

じゃ、俺からの反原則Freeの連中の評価。
・リピートだけしてる箱に比べてまとも。
・リピートだけしてる箱に比べてウザくない。
　　なぜならリピートだけじゃなく議論「も」やっていて、
　　毎回ちょっとずつ新しい※知見・再確認があるから。

　　※：新しいってのも相対だ。最近はネタ枯れ気味だし、
　　　　さらに１年経ってもやってたらこっちもウザいと
　　　　感じるかも知れん。

例えば
毎朝通る駅前にいつも同じ内容の微妙におかしな演説する奴がいて
しかもうっかりと丸ごと信じる間抜け(Sugihara)もいる状況で一言、
「おめーの理屈おかしーよ！」
と釘さしていく通勤客が数人、てとこだな。

口やかましい連中と思うし、手本にはしたくもないが
そういった人間がいないと正論が通らない社会になっちまう、
それくらいの事はわきまえときたいもんだ。

追記。
>俺を貶めて悦に入りたいの？

もし「貶められた」状況にあんたがあるとしたら、
その材料を提供したのはあんたのカキコ自体だ。
読み返してみなよ。私怨、だか変な自己投影、君。

>なんの説得力も内容もない発言を繰り返しても、
>俺の考えは変わらないよ。

あんた個人がどうなろうと知った事ではない。
ひとり粘着道をまい進して下さって結構。
しかし目立つネットニュース投稿者（２ちゃんで言えば
固定ハンだな）叩きに血道を上げる粘着君の愚かさ、
浅さが分かりやすい形で表されていたので格好のサンプル
としてあんたの粘着カキコ、利用させてもらった。

君の書いている文章を読むと、ほんとここが2chなんだなー、って思うよ。

それ以上でも以下でもない。内容無いし。

>もし「貶められた」状況にあんたがあるとしたら、
>その材料を提供したのはあんたのカキコ自体だ。

なんかさー、日本語日本語って言う割には、論理展開できてないんじゃないの？
ま、どうでもいいんだけど。
俺は粘着だから書いといた（藁

>>340
> それ以上でも以下でもない。内容無いし。
オマエモナー（そう思うんだったらsageろ）

>あのな、言っとくが国語の勉強は大事だぞ。
>既存の言葉を勝手に再定義するなら尚の事だ。
>「絶対」という言葉にはそんな意味などない。
>せめて「独立評価」ぐらいにしておくべきだったな。

http://www.google.com/search?sourceid=navclient&q=%90%E2%91%CE%95%5D%89%BF
約3,480件中1 - 10件目 ・検索にかかった時間0.08秒

ごめん、俺って粘着なんだ（藁

独立評価
http://www.google.com/search?sourceid=navclient&q=%93%C6%97%A7%95%5D%89%BF
約62件中1 - 10件目 ・検索にかかった時間0.46秒

>>342
>> それ以上でも以下でもない。内容無いし。
>オマエモナー（そう思うんだったらsageろ）

俺に煽って欲しいの？
粘着だよ？俺って（藁

>>338
最近のfj.news.usageとかjapan.yosoを読んでみなよ。
鶴田の電波ぶりが堪能できるから。

ひょっとして、君、鶴田？
その言語センスがよく似てるよ。「必要論争」みたいな。（藁

>>345
はやく煽れよ(プ

>>346
> ひょっとして、君、鶴田？
じゃあひょっとして、君は箱ですか？

# 詮索君、決め付け君はやめようぜ。

　　　　∧ ∧　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　（ ﾟДﾟ） 目＜　　ケンカをやめてぇ〜♪
　　　　 |つ つ　||　 |　　ふたりを止めてぇ〜♪
　　　〜　　 |　 .||　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　∪ ∪ 　.||

おお、止まった(w

> 河野 真治@琉球大情報工学です。
>
> In article <[email protected]> ,
> "Sugihara Yoshimi" <[email protected]> writes
> >原則free()は
> > オブジェクトの寿命が終わったら速やかにfree()する
> >ということです。仕様変更でオブジェクトの寿命が延びたのなら、
> >それにあわせて設計も変化します。
>
> 原則 free でなくて、
>
> 不要になったとマークする
> 領域を同じオブジェクトとしてモジュール内で再利用する
> 領域を他のモジュールが使えるように解放する
>
> という三段階で設計して下さい。モジュール化/オブジェクト指向化
> した段階で、単純な malloc/free は、ほとんど禁止なのかもね。
> たぶん、memory pool を使うようになると思います。

河野さんっていつもどんなもを設計して、どんなものを作ってるんでしょうね。
原則freeに相対する手法として、これを持ち出すのはどうだろう。

Sugihara氏に対する片山氏のフォロー

> >仕様変更に有効でもあるでしょうが
> >複数の人間がかかわるような設計なんかの場合は、最初の設計段階から
>
> > この処理はこの関数に任せるから好きにやっていいよ
>
> とできるような簡単なプログラムしか経験していないのでしょうね。

なんで、この人、こういうこと言いたがるんでしょうね。
言わなきゃ尊敬されると思うんですが。

箱氏に対する片山氏のフォロー。

> > だったら、はじめからそう書けば良いんじゃないですか ? 少なくとも、貴方が
> >「何処で...」なんて書かなきゃ、「定義場所」なんてことは書きませんよ。
>
> そこまで日本語に不自由しているとは想像できませんでしたから。

と、一行だけのフォロー。
・・・。

もともとの鶴田氏の主張。（途中の引用部は箱氏のもの）

> > Shin-ichi TSURUTA <[email protected]> wrote:
> > > 必要性を検討して、必要なら実装するのが良い習慣です。
> > とおっしゃっている方がいますが、検討すること自体のコストと危険性を、
> > それこそ
> > 何も「考えていない」としか思えません。
>
> そう思うのは設計ができないことを告白しているようなものです。
>
> freeやmallocを書き始めてから、検討するのではないのです。設計
> 段階ですべて決める。
>
> 個々について検討するというより、全体から個々の必要性が自動的
> に定まるという感じですね。

箱氏の鶴田氏への質問。

> 私は、「つまりコーディング前に全ての free()/malloc() までが決まってい
> るんですよね。」と聞いているんですよ。リソースについてなんて書いて頂かな
> くても結構です。(話が発散するだけですからね。それともそうしたいの ?) と
> にかく、貴方の言う「きちんとした設計」をした時は「コーディング前に全ての
> free()/malloc() が決まっているのですか ?」に対して、Yes/No でお答えくだ
> さい。

それに対する鶴田氏のフォロー。

> 質問が良くわからないのですが、私の場合、free()/malloc()を書く
> こと自体をコーディングと呼んでおります。設計ではありません。

それに対する箱氏の再質問。

> だれも「free()/malloc() を書くことをどう呼ぶか ?」なんて聞いてませんよ。
> コーディングを行う前に、free()/malloc() をするかどうかが決まっているかを尋ね
> ているだけですよ。
>
> # 何で答えられないかなぁ ?

鶴田氏の答。

> プログラマに対して必要かつ理解できる情報は既に示しています。

*

要するに鶴田氏は、free()/malloc()を書くこと自体をコーディングと呼んでいるのだから、
箱氏の質問
「コーディング前に全てのfree()/malloc() が決まっているのですか ?」
の回答は
「決まっていない」
ということなのだろう。

それって、鶴田氏が自分で言ってるところの「設計が出来てない」っつーことでは・・・。

鶴田君って、自分の日本語能力をきちんと把握してるみたいだから、
なるべく長文は書かないようにしてるみたいだね。

相変わらず、論理展開が出来てないし、
（あ、ここ、どこがどう出来てないか、っつーつっこみはやめてね。
面倒だから。「どうせ、出来ねーんだろ」という評価でも俺はOKさ）
すぐに、ぼろがでちゃうし。

で、
> プログラマに対して必要かつ理解できる情報は既に示しています。
のような仄めかし（のようなもの）をして、精神的安寧を求めてるのが
見え見えなのが、郷愁を(?)誘うね（ｗ

つーか、この人、何が目的でfj.comp.lang.cに書き込みしてるんでしょうね？

>>355
>郷愁を(?)誘うね
君の田舎はこんな人ばかりなのか? (w

>>356
なにいってんの？
君、やっぱり、鶴田なんだろ。

文章のダサさかげんがママだよ（ﾌﾟ

Sugihara Yoshimi うざい。

signal 受信時に free するため、malloc した部分を外においておくという考えがステキ。
自分のプロジェクトにこういう人間がいたら絶対に止めさせるだろうね。

他人は全て同一人物で鶴田かよ。粘着はさっさと病院逝け。

>>357
「郷愁」という言葉に >>356 は反応したものと思われ。
知らない言葉だったら無理して使わないほうがよいと思う。

>>358
結局上位のレイヤー使ってない（分かってない？）との自白と思われ。
奴にハードウェア制御は怖くてやらせられないな。

結局、粘着＝箱だったの？
粘着のいってる内容って何？
引用並べてコメントすること？
ｻﾊﾟｰﾘわかんねえ。

それよか comp.arch.fpga の i8080A 互換 CPU & CP/M スレ見れ

>結局、粘着＝箱だったの？

ちゃう。

>粘着のいってる内容って何？
>引用並べてコメントすること？

そう。
目的は、鶴田氏と片山氏の批判。
両氏の発言を読んで、やりきれなくなった想いをここではらす(ﾜﾗ

鶴田氏の発言（引用部分はＳｕｇｉｈａｒａ）。

----
> そもそも、不正な命令（SIGILL)や不正なメモリアクセス（SIGSEGV)が
> 起こるようなプログラムの方がメモリリークよりもよっぽど問題だと
> 思いますけど

ですよね？というか、そうであるからこそ、不正な命令等のために
大域空間を汚すのではなく、素直にexitしてしまえばいいのではな
いでしょうか？おっしゃる通りその場合はメモリリークなど問題に
ならないわけですから。

メモリリークより遥かに問題な場合なのに、メモリリークしないこ
とを考えて大域空間を汚す理由って一体何？気休め？
----

あー、なんでこいつって、こんなに論理展開が下手なんだ。

>メモリリークより遥かに問題な場合なのに、メモリリークしないこ
>とを考えて大域空間を汚す理由って一体何？気休め？
は、省略された主語を補いちょっと表現を変えると、

----
不正な命令（SIGILL)や不正なメモリアクセス（SIGSEGV)が
起こるようなプログラムの方がメモリリークより遥かに問題なのに、
メモリリークしないことを考えて大域空間を汚す理由って一体何？
気休め？
----
となる。「のに」の前後が繋がっていません(ﾜﾗ

あー、こいつ、やっぱり気軽に叩ける相手を見つけては、
自分の心の安寧を追い求めてるんだろうな。
郷愁(?)を誘うね(ﾜﾗ

Ｓｕｇｉｈａｒａは言うまでも無く、片山氏や鶴田氏や、箱氏にさえも
はるかに劣るけど(ﾜﾗ

まぁ、こいつがいつまでもfj.comp.lang.cにしがみついてることの
方がよっぽど謎といえば謎だな(ﾜﾗ

>>363
だーかーらー郷愁ってなんなのよ。私も >>356 同様
「あんたの故郷はそういう奴ばっかりだったのか？」
との疑問が頭を離れません（苦笑）
「憐憫の情を誘う」とかだったら文意が繋がるんだけど。

で、上記「郷愁」の意味がわからない国語力の私には
「のに」の前後で文意は繋がってるように見える。


Sugihara に関して言えば、典型的な不勉強プログラマなのに
なんでわざわざ fj.comp.lang なんぞに顔を出してんのかが疑問。
プログラム経験はコマンドラインのフィルタをいじった程度と
見積もってます（値踏み癖）。
まー comp.lang.c でないだけましだが。つーか来んな。

箱氏、japan.comp.windows2000やjapan.handmade.compじゃ普通なんだけどな。
なんであんなんになっちゃったのか。

また箱がどっさり投稿してきましたな。

ほんとにいつになったら終わるんだか…。
もはや意味の無い論争なのでメールで直接やりとりしてくれ。

あげるな

>>368

別にあげても構わないだろ。たいしたこと書いているわけじゃないんだし。
とかきつつ sage。

>>365
>だーかーらー郷愁ってなんなのよ。私も >>356 同様
>「あんたの故郷はそういう奴ばっかりだったのか？」
>との疑問が頭を離れません（苦笑）

うむ、そこまで気になるのなら説明しよう。
「郷愁」はあなたが言う通りの辞書的な意味で書いている。

>「憐憫の情を誘う」とかだったら文意が繋がるんだけど。

俺の心情的には「憐憫の情を誘う」ような感じなんだが、なぜだか
彼（鶴田氏）の発言を見ていると、どうしても小学生のころを思い出す
んだよね。理由はわからないけど。

その意味で彼の発言は、俺にとっては郷愁を誘うんだよ。
一般に使われる意味で「郷愁を誘う」のではないので「(?)」をつけといた。

>で、上記「郷愁」の意味がわからない国語力の私には
>「のに」の前後で文意は繋がってるように見える。

うん、あなたが「繋がってる」と思うのなら繋がってるんだろう。
これは議論しない。

ただ、一見「論理性」で売ってる鶴田氏の文章としては、あまりにおそまつで
まぎれがある文章だろう？

# age荒しと区別するためにコテハンにしたよ。叩くなら叩け（ｗ

俺が鶴田氏を嫌ってるのは、ある人に対して、最初は尊敬語や丁寧語で
語りかけて、あとから態度をコロッと帰るところなんだ。

>>363で引用した彼の発言も、尊敬語と丁寧語を使ってるだろ？
見ててごらんよ、そのうち「君よばわり」「馬鹿よばわり」「無能よばわり」
「日本語読めない奴よばわり」を始めるから。

仮にＳｕｇｉｈａｒａがそういう人間だとしても、鶴田氏がfj.comp.lang.cで侮蔑的
発言を撒き散らして良い理由にはならない。

俺はそれがイヤなんだ。

漏れも鶴田の書き出しが嫌い。

チャットじゃねーっつうの。

>>372
鶴田のあの書き出しはおそらく彼の尊敬する木屋善夫氏を真似たものだろう。
木屋氏はかの有名な XANADU の作者。2, 3 年前は fj.comp.lang.c++ で
よく見かけたが最近見ないな。

　C Language的には、
「処理系依存（核爆）」
だろ!!

age荒らし逝ってよし

>>373
マネだったノカー！ますます恥ずかしいね（ｗ

>>370
郷愁の意味は判ったので了解。
個人の内部で完結してる連想に噛み付きゃしません。

個人的にお付き合いしたくはないが
遠巻きにウォッチするなら有用な人物と思ってます。＜鶴田氏評
だから彼が罵声を他人に浴びせても無問題。
罵声の「内容」は概ね正しいしね。

松本登場！

箱氏に対するフォロー。

<[email protected]>
> 相変わらず日本語に不自由してますね.

出ましたね、伝家の宝刀が。
でもね、君みたいな日本語が不自由している人が言うと、
まったく説得力が無いんだよ(ﾜﾗ

Sugiharaもそうだけど、この松本 洋暁というのも、
一体何を求めて議論しているのか良くわからん。

松本 洋暁の箱氏へのフォロー

<[email protected]>
> 相変わらず文脈が読めないですね.
...
>> # 混乱させたいだけ ?
>
> 箱さんがそうだというのはわかりました.

なんだ？こいつ。

橋本　剛 登場！

誰か、
<[email protected]>
について、解説してくれ。長くて読めん。

えー、鶴田です(藁)。スマソ。
まさかこんなところで叩かれてるとは思いもしませんでした。
私がウザイのはわかりました。以後気をつけたいと思います。
# アホな記事見かけるとついフォローしちゃうんだよな…鬱だ氏のう

アホやバカを見つけると突っつきたくなる人は良くいますよね。

>>381
といいつつageてるじゃん、鶴田君(ﾜﾗ
本物(?)登場により、鶴田君を叩くのはしばらく控えるよ。

本人がここで watch されていることを投稿したようなので、
更に数人流れてくるかもしれませんね。

というか、メルアド入れなくていいから。メール欄は sage で。

ほぉ、本人だったのか。

リンクを張られても尚、

「2chなぞというUGな場所には近づきませぬ。
私は2chなぞ読んだことありません。」

とかいう馬鹿が登場しそうな予感。

>>384
ゴルァ！！！好きなスレだから俺は上げるぞｺﾞﾙｧ！！！ヽ(`Д´)ノ

もうネタはいいよ。

>>385
今時２ｃｈをＵＧだと思ってる奴なんているのか？

いるでしょ。

つ ー か a g e ん な。

>>383
> 叩くのはしばらく控えるよ。
ヘタレ野郎だな。
2chでこっそり叩いてて、本人出てくると遁走かい？

>2chでこっそり叩いてて、本人出てくると遁走かい？

その通り。最初から俺はそういう奴だと表明してるじゃん。
俺は絶対安全地帯が好きなんだよ(ﾜﾗ

鶴田君が俺の書き込みに対して質問・意見があるなら
答えるけど。

>>390
>ヘタレ野郎だな。
>2chでこっそり叩いてて、本人出てくると遁走かい？

俺を叩きたくなる君なら、何故俺が彼らを批判したがるのかが
わかるだろ(ﾜﾗ

Sugihara Yoshimi がこのスレを「面白かった」だってよ...
例によって、ここでも何を議論しているのかが理解できないのか (w

>>391-392
> 最初から俺はそういう奴だと表明してるじゃん。
知らんかった、粘着と表明しているのは知っていたが？
粘着だったら遁走しないで本人とやりあえよ。見てるから。

> 何故俺が彼らを批判したがるのかがわかるだろ(ﾜﾗ
わからない。もしかして>>371の
> fj.comp.lang.cで侮蔑的発言を撒き散らして良い理由にはならない。
ですか？

実名で投稿していてリスクも自分で負っているfjだと侮蔑的発言は許されなくて、
匿名で書き込んでいて安全地帯の2chだと侮蔑的発言は許されるの？

# さっぱりわからない

>>393
俺もその記事読んだよ。その一言だけだったね。案外自分の無知・厨房・ﾄﾞｷｭｿ
っぷりに気づいて愕然としていたりして…。

# っていうかそうあってくれ。二度と fj.comp.lang.c で自分が理解しても
# いない議論にちょっかいを出すな。もっと勉強しろ。

鶴公も二度とあのくさい登場の仕方すんなよな。
わかったな、鶴！返事しろ！（藁

大幅に出遅れたな…
本人登場しちゃあまり美味しくないよ、このスレ。

>>380
自分でベン図書きながら読めば理解できる。
ややこしい場合分けやったことあるなら出来るはず。
でも一般的な論理学の用語とちょっとズレないかい？ ＞識者

|｜　　∧ ∧
|｜　　ﾐ・ο・ﾐ 　はにゃーん
|｜〜（,,ｕｕﾉ
~~~~~~~~~~~~~~~

もう旬は完全に過ぎちゃったけど、
コッソリとヲッチャーは Sugihara だった説を提唱してみる。

なんかタイミング的に fj で彼が叩かれると
こっちでヲッチャーがその叩いた相手を叩いてたし、
技術的な中身に踏み込まないスタイルが似てる。

>399
それおもしろい。そういうことにしよう。
つーか、あんがいあたってそう。

んでよ〜結論としては
「いみないことに時間かけてるよ」
でいいのかね？
明日までレポートにしなくちゃいけないから。

free 必須派の言う（実はどうにも半端な）再利用をするつもりがないなら、
malloc-free の対称性なんぞ気にしなくてよいのでは。

>>399
>コッソリとヲッチャーは Sugihara だった説を提唱してみる。
ちゃうよ。

うお、失敗。再度。

>>394
>実名で投稿していてリスクも自分で負っているfjだと侮蔑的発言は許されなくて、
>匿名で書き込んでいて安全地帯の2chだと侮蔑的発言は許されるの？

さぁ？そんなこと自分で考えたら？(ﾜﾗ

>>399
>技術的な中身に踏み込まないスタイルが似てる。

それはスタイルではなくて、目的が違うから。
俺は一貫して、彼ら（片山氏と鶴田氏）のfj.comp.lang.cへの書き込みが、
場にそぐわないし、ウザイからやめてくれと主張してるだけだよ〜ん。

ちなみに、ここで鶴田氏へのコメントをやめるというのは、彼が

>>381
>私がウザイのはわかりました。以後気をつけたいと思います。
># アホな記事見かけるとついフォローしちゃうんだよな…鬱だ氏のう

と言ったから。
またくだらない発言をしたら、ここでお披露目しちゃうよ〜ん。

# 今日の冒頭の発言でageてしまって、ｽﾏｿ

ああ、それから俺がここで技術論に踏み込まないのは、
fj.comp.lang.cの書き込み全部をフォロー（意味通じるよね）
してるわけじゃないから。

そんな暇ないよ〜ん。

>>390
>粘着だったら遁走しないで本人とやりあえよ。見てるから。

何で本人に振るのさ。
君が俺の書き込みに対して何か含むところがあるなら、
君が発言すればいいだろうが。

君こそヘタレ〜(ﾜﾗ
君こそヘタレ〜(ﾜﾗ

まぁ、俺はクズだけど、卑怯者にはなりたくないんで、付き合ってやるよ。

ヲッチャーうざい。age んなって言う前に、自分の言いたいことを
まとめてから書き込めよ。短時間に6連続書き込みすな。

sageろ、sageろって言うなら、自分の web でも開いてそこで
やってくれな。自分の発言が age る価値がないことを自覚してるんなら、
最初から発言するな。

>>410
>sageろ、sageろって言うなら、自分の web でも開いてそこで
>やってくれな。

あー、君って人の謝罪を受け入れない人なんだ。
そんなことだと、どんどん世の中狭くなるよ(ﾜﾗ

>自分の発言が age る価値がないことを自覚してるんなら、
>最初から発言するな。

おいおい、今度は2ch否定論かい？
お約束「イヤなら来るんじゃねーよ」(ﾜﾗ

なんだかんだ言っても、連続発言ばっかりしてるのはイタイな。

誰かキチガイ警報のコピペ頼む。

　ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ　ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ
　　　へ　　) 　 へ　　)　　 へ　　) 　　 へ　　) 　　へ　　)　　　へ　　) 　 へ　　)　　 へ　　) 　 へ　　)
　　　　　　> 　　　 　>　　　　　 > 　　　 　 >　　　　　 >　 　　　　　> 　　　 　　>　　　　　 > 　　　 　 >
┌───────―――――――――――――─────────―――――――――──┐
│　　　　　　(　ﾟ ∀ﾟ )　　　　　　　　　　　　(　ﾟ ∀ﾟ )　　　　　　　　　　　　　　　　　　　　ヽ（　ﾟ ∀ﾟ )ﾉ 　　　｜
│　　　(　ﾟ ∀ﾟ )　　　　　　　　　　　　　　　最大級キチガイ警報！！！！！！　　　　　　（　　へ　　　　｜
｜　　　　　　　　　　　(　ﾟ ∀ﾟ )　　　　　　　　　　　(　ﾟ ∀ﾟ )　　　　　　　　(　ﾟ ∀ﾟ )　　　　　　く　　　　　　｜
└―――──――――――――――――――――――――──―――――――――――――┘
　　ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ　ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ ヽ(ﾟ ∀ﾟ )ﾉ
　　　へ　　) 　 へ　　)　　 へ　　) 　　 へ　　) 　　へ　　)　　　へ　　) 　 へ　　)　　 へ　　) 　 へ　　)
　　　　　　> 　　　 　>　　　　　 > 　　　 　 >　　　　　 >　 　　　　　> 　　　 　　>　　　　　 > 　　　 　 >

おい、まだfjで続いてるよ。
しかもとっくに論破された内容の延々くり返し。
箱まじうぜぇ。

だからリピート病だって。Sugihara は知ったか病な。
もうあの二人は fj.comp.lang.c の東洋海亀(Naoya Kinjo)なんだよ。

Sugiharaあいかわらず痛すぎ
「面白かったです」で自覚してくれたかという期待もはかなく

論理的に考えられない人間に、論理的に説明して何になるんだろう。
時間の無駄と思うんだが、彼らに何か得るものがあるのだろうか。

>>418
しかし fj.comp.lang.c は論理的な話をするところだからねえ。
非論理的な投稿に占拠されるわけにいかないんじゃない？

論理的に対応して引き下がってくれるかというと確かに疑問だが、
他にどうすればよいんだろ。

まさか「厨房は逝ってヨシ」で消えてくれるとも思えんし。

freeくらい書け糞どもが

free書いちゃいけないときってあるの？
とりあえず全部freeしてるけど。

>>420, >>421
fj.comp.lang.c くらい読んでから出直して来なさい！

それが面倒だから聞いてるのby厨房

>>423 厨房は逝ってよし（これで満足いただけたかな？）

論理的にものを考える人は、相手も論理的にものを考えると勝手に仮定し
ていますが、これは常に正しいわけではありません。
この仮定が成り立つのは、感覚的には5割ぐらいでしょうか。

＜相手も論理的
人にもよるし、話題にもよる。

箱氏は他のニュースグループではわりとまともな投稿をしている。
しかし fj.comp.lang.c では単なるプロパガンダのみ※で、議論できていない。
※これは、誰かが嫌いな Sinichi-Tsuruta 氏の指摘。

がいしゅつだけど、まともに free してないコードのお守りを
させられてトラウマになってるんではないでしょうかね。

>>56
> malloc/free論争って要するに規格を拡大解釈することを良しとするかしないかを争ってるんですよね?

いや、規格を杓子定規に解釈することをよしとするかしないかを争っている。

で、これ、どちらなのかも争っている。

そんなメタな争いに意味があるかどうかや、投稿者のパーソナリティについても。

邪馬台国がどこにあるかについては争ってないみたいだな…

>>427
fjから流れてきたの？ いちおう最後までスレ読めば？

fjではもう実質終わってるよ。free原理主義者の残党が消耗戦を試みてるだけで。
ずっと以前から大勢は決してたけどね。

実名だと引っ込みつかなくて大変だね〜。
って箱は実名じゃないのに引っ込みつかんビョーキらしいが（W

> 実名じゃないのに引っ込みつかん

それなんだけど、誰かが確かこういう指摘をしていた。
「今までそういう（malloc-free を必要なくても対称的に使う）コードを
　作ってきたので、いまさら認めるわけにはいかないからだろう」
（これ >>426 と同じで鶴田氏だったかも知れない）

俺はコーディングも設計も、基本方針がずるずると変わってきたんで
（最近だとデザパタ意識）今ひとつ判らんのだけど、スタイル不変な
（＝不勉強なのか用心深いのか）人だと「あんたのコードはイマイチだった、
なぜなら…」と論理的に詰められても認められないのだろう。

組み込み系・基幹系にこういう反応する人が多いと思う。
それが用心深いせいだったらある意味、美徳だし。

ただ、「malloc-free 対称を用心して守ってリーク予防」なんてのは
「goto 禁止」と同程度、「初心者のうちに済ましとけよ」レベルだと思う。

>>429
> 「goto 禁止」と同程度、「初心者のうちに済ましとけよ」レベルだと思う。
えっ、「ハンガリアン記法」と同じで「根拠レスの精神論」レベルだと思ってた。

>>430
そっちでもいいよ。
「済ましとけ」なのは、はしかみたいなもんだと思ってるから。
はやめにかかって直ればよし。でも長年やっててかかると…

>>429
え？malloc-free対称を用心して守っておけばリーク予防になるんじゃないの？

>>432
まだいたよここにも。
fj読めば。それかfjで訊け（藁

>>433
何でならないの？
つーか、君fj読んでないだろ。それとも書かれてる内容が理解できんのか？

>>434
読んでるよ。去年のもね。

対称とかまだ思ってるんなら
fjに乱入してもっかい叩かれてみれば（W

何でならないのか、説明してみろよ。

freeが必要ならする。必要ないならしない。
どこに「原則」とか「デフォルト」の入る余地があるんだろ？

>>436
対称ならスタック使えば？ その方がよっぽどいいっしょ。
つーか、exit前のfreeにリーク関係ないじゃん。

>>438
おいおい、誰がexit前のfreeの話をしてるんだよ。
「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
を話してるんだよ。

>>438
パンがなければケーキか。
んで、小麦粉はどこから持ってくるのかな？

なんだ。じゃあfjとは関係ない話だね。
漏れは予防にはならないと思うけど、まあ勝手にすれば？

>>441
うーん、その「ならないと思う理由」を聞きたいんですが。

>>439
> 「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
mallocで構築するデータに対称性があるならリーク予防になるだろう。

しかし、malloc-freeは対称性のないデータ構造にも対応できるように設計されている。
対称性のないデータ構造に無理に対称性を持ち込むのはリーク予防どころか有害無益。

>>443
対象性のあるデータってどういうものですか？

>>429
だって、組込系はほとんどの場合exitしないぞ。
それどころか、一度プロセスが動き出したらユーザが電源切るまで
動き続けてたりするんだもん。

439 実際のプログラムで常に対象性を維持できるのであれば、それで
いいのではないでしょうか。対象性に拘るのが無意味もしくは、有害
な例として、exit前のfreeは、この問題に十分関連があります。

今度は2chで論争ですか。
頭悪いんですか？
ま、せいぜいsageで罵り合っててください。

なんかさfjの議論で「必要なのにfreeしない厨房」が増えたような気がしない？
>>443とかもわかったようなこと書いてるけど、微妙にはずしてるし。

>>447
ははは、反論できずに逆切れですか。
いいですな、2chでは逃げが打てて（藁

exitするプログラムしか書かない奴と、exitをしないプログラムしか
書かない奴との争いだったんだ。

んだから場合によるんだから「原則」なんぞにするなってこと。

>>440
対称ならスタックで良いのにわざわざmalloc使ってリークの心配を持ち込むのは馬鹿げてる。

>>451
ん、誰も「原則」なんて持ち出してないよ。

「スタック」ってスタック構造のことを言ってる？
mallocが必要になるから、mallocするって文脈で、スタック構造が
登場する余地はないと思うけど。

複雑なデータ構造ばかりを扱うような人は「単純にバッファが必要に
なるからmallocして、いらなくなったからfreeする」って構造がわから
ないのかな？

俺は、いつでもmalloc-freeの対象性を保てるとか、保つべきとか
必要ないとか言ってるんじゃなくて、

「対象性を保てばリーク予防になるでしょ？ならないという人は説明して。」

と言ってるだけなんだけど。

>>452
メモリ領域のスタックと思われ

そのメモリ領域がスコープ外でも有効である必要がある場合は少なくないと思うが。

>>452
もーfj.comp.lang.cの中身を繰り返すのはめんどくさい。

(「いつでも」なんてこっちも言ってなくて)
ほんとに対称性を保てる場合ならスタックで十分でしょ
そしたらそもそもリークの心配なんて不要でしょ
ってのはfjで出てきてたよね。

やっぱ読んでから出直して。

>ほんとに対称性を保てる場合ならスタックで十分でしょ

え？サイズも個数も不明だからmalloc使うんでしょ。

>そしたらそもそもリークの心配なんて不要でしょ

だから、そういう心配をしてるんじゃなくて、

「対象性を保てばリーク予防になるでしょ？ならないという人は説明して。」

って言ってるんだけど。
なるの？ならないの？

っていうか auto_ptr 使え！
〜〜〜〜〜〜〜〜終了〜〜〜〜〜〜〜〜〜〜

>>452
> 対象性を保てばリーク予防になるでしょ？
その通りです。

で、なんで対称性のないmalloc-freeで無理に対称性を保とうとするのでしょう？
説明して下さい。

＞もーfj.comp.lang.cの中身を繰り返すのはめんどくさい。

fj.comp.lang.cの中身も理解していないし、人の発言も読んでないんでしょ。
んで、頑迷に「スタックで十分」「fjを読んでから出直せ」と繰り返すのみ。

もういいよ、無理しなくて（藁

>で、なんで対称性のないmalloc-freeで無理に対称性を保とうとするのでしょう？
>説明して下さい。

話が逆。
malloc-freeを対象性を保ってつかう ⇒ リークの予防になる
という話をしてるの。

＞＞４５７
C言語の話なんですが･･･。

>>460
話が逆だろ。
わざわざ対称性のないmallocとfreeを対称に使う努力するぐらいなら
もともと対称なスタック使えば。

malloc()とfree()は対象性があるとでも言って欲しいのだろうか。

>>456 >>459
この人Sugiharaと同じこと言ってる（プ
news:[email protected]

>>460
処理系依存になるがallocaを使うか、
C99の可変長配列でも使え
〜〜〜〜〜〜〜〜終了〜〜〜〜〜〜〜〜〜〜

>>462
>>432-435 で、笑われたからここまで引きずってるんだよ。

誰もmallocとfreeは対象性があるなんて言ってないよ。

>もともと対称なスタック使えば。

俺は一貫して「対象に」を副詞で使ってるけど、君は形容詞だと
思ってるから話がずれるんだよ。

スタックの話は君から言い出したことだけど、「スタックで十分」じゃ
ないから、mallocを使うと言ってるのがわからない？
スタックで十分じゃない場合を想像できないとかか？

>>464
だから何？
間違ったこと言ってると思ったら反論してみろよ、クズが。

誤字ネタじゃなかったの？
んじゃ「対象性」ってなに？

> 誰もmallocとfreeは対象性があるなんて言ってないよ。
うん、誰も「対象」なんて言っていないね。
# 「対称」とはいっているが。

> 俺は一貫して「対象に」を副詞で使ってるけど
「対象」と書いてあるメッセージID（レス番号）を示して下さい。

>>467
だからfj.comp.lang.cで終わった話をくり返すなっつーの。

対称の間違いでした。
でも、この変換ミスは致命的な瑕疵とはならないと思うけど。
ということで、>>466から続けてくれ。

>>470
またまた反論できないんだね。
人の言葉を借りずに、自分の言葉で何か言ったら？

要するにアレだ。
fj.comp.lang.cをちょっと齧った厨房が、malloc-freeをペアで使うことさえ
罪悪だと思ってしまってるんだろ？
「対称性を保って使う == ペアで使う」
だよ。本気で解らなかったのか？

>>472
マジでfj読んでから言ってるの？
だってこの先fjにあったのと同じ受け答えをくり返すのはうざいし。

fjで終わった（Sugiharaと、あと誰かもう1人が負けて黙った）先から続けてくれない？

>>474
＞あと誰かもう1人
片岡だろ。「対」とか「ペア」とか言い続けて砕け散った（ワラ

ここで「ペア」蒸し返そうとしてるやつがいるし（ワラ

>>474
はぁ？
だから俺が間違ったこと言ってると思うなら反論しろよ。

まずは何が間違ってかから挙げてみろ。

つーか、お前ら俺の書き込みを読んでないんだろ。

単語に脊髄反射するんじゃねーよ。

> 「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
リーク予防になる

しかし、「malloc-freeは常に対称になるとは限らない」
でいいのか？

>>476
反論はfjに出てたよ。３月頃。

>>477
読んでるよ。fjとおんなじに見える。
違うとこがあるなら、そっからやれば？
（fj読んだんならどこが違うか言えるでしょ？）

・寿命がスコープ外に及ぶ
・サイズも個数も実行時に決定
・exitしない

というケースはそんなにレアですか？

>>478
いいよ。

>しかし、「malloc-freeは常に対称になるとは限らない」

これにちょっと追加。
mallocとfreeは対称性があるものでも、対象性を保って使わなければ
ならないものでもない。

ただ、対象性を保って使える場面は数多く存在するし、
そういう場合に対象性を保って使っておけばリークの
予防になると言ってるんだけど、そんなに解りずらい
文章だったか？

>>479
おいおい、俺の発言に対する反論がfjに出てるワケないだろうが。

俺の発言で誤っている個所を指摘しろって言ってるんだが、わからんか？

スタック、スタックとお題目を唱えてる>>462は、スタックが無限であると思っているし、
再帰も使ったこと無いと思われ。

>>482
あーもーめんどくせーなー。
「あなたさまの発言とそっくり同じ内容の発言がたびたびfj.comp.lang.cに出てました。それはきれいに言い負かされてました。いちいち同じやり取りをここで繰り返すのはうざいです。もしちょっとでも新しい内容があるならそこから始めてくださいませ。」

これでいいか？

>>484
馬鹿か、お前。それともほんとに日本語読めねーのか？

>そっくり同じ内容の発言

俺の発言のどこがそれなのか指摘しろつってるだろーが。fjの威を借るウジムシくん。

>>481
> そんなに解りずらい文章だったか？
うん、解りずらい。
対称と対象が入り交じっていて（以下略）はネタとして

原因としては俺が
> 対称を用心して守っておけば
を「常に対象にできる」ニュアンスが含まれていると誤解した。
481で誤解が取れた。

君に反論しているのは俺以外に少なくともあと１人いる。
俺は消えるけどまあ頑張ってくれ。

>>486
>うん、解りずらい。
まぁ、推敲もせずに書き込んでるから、その辺は許してくれ。

>481で誤解が取れた。
あぁ、良かったよ。永遠に続くかと思われたよ。

>君に反論しているのは俺以外に少なくともあと１人いる。
うむ、俺も少なくとも2人を相手にしていると思ってた。
残りの一人が厨房度が高そうなんだけど、根拠無き中傷は
許さんから、徹底して相手するつもりだよ（藁

>>485
＞ 俺の発言のどこがそれなのか指摘しろつってるだろーが。
「ペアにして使うように気をつければリークが減る」
「（対称でも）サイズも個数も不明だからmalloc使う」
「（対称でも）スコープ外でも有効だからmalloc使う」

もー同じこと何度も何度も何度も何度も。
これらへの反論はfj見ろよな。（つーか、見たんだろ？なんで繰り返す？）

＞fjの威を借るウジムシくん。

へえ。いまどきfjに威なんてあるの？
繰り返しがうざいだけだよーん。

あーもーめんどくせーなー。
やめ、やめ。厨房で結構。

>>48
ん、>>489は荒らしか？

>>488
>>480の発言は俺じゃないし、俺が「指摘しろ」と言ったのは>>476だ。
君の世界では、時間も狂ってるのか？

>「ペアにして使うように気をつければリークが減る」
これは確かに言った。
で、間違ってると主張するんだね？(Yes/No)

だとしたら、何か反論するか君の得意なfjでの反論のMessage-Iｄでも
示してみろよ。

言っておくが「ペアにして使うように気をつければ」ということに関して
議論してるんじゃないぞ。

「リークが減るのか減らないのか」だ。

「mallocしたらfreeが必要かどうか」を論じてるんじゃなかったのか。
そこへ「malloc使わない」というのを持ち出すのはどうかと思うが。

「目玉焼きに書けるのは醤油かソースか？」という議論の最中に、
「スクランブルエッグを食え」という発言は有効か？

>>488
>「（対称でも）サイズも個数も不明だからmalloc使う」
こんなこと言ってないぞ。

君の言う形容詞の対称とは、いったい何を形容してるんだい？教えてくれ。

>サイズも個数も不明だからmalloc使う

これは言ったが、何か反論でもあるのか？
まさか、mallocを使うなと言いたいわけじゃないだろうな。

>>485 >>492
えーと、fj でのやりとりはこちらでご覧になれますよ。

http://queen.heart.ne.jp/cgi-bin/browse?msgid=<[email protected]>
から順に「フォロウ記事」を追ってみてください。

malloc-free は宗教だと思う。

失敗。セミコロン挟まってた。正しくはこちら。
http://queen.heart.ne.jp/cgi-bin/browse?msgid=<[email protected]>
http://queen.heart.ne.jp/cgi-bin/browse?msgid=<[email protected]>

タグ挿入防止のための仕様でしょうか。やれやれ。
自動的にセミコロン挟まってるようなので「＜；」の「；」を取ってください。

>>493
残念ながら、その議論ではありません。
あなたも勘違いしていると思います。

俺の主張は>>490です。

さらに言えば、「いかなる場合でもmallocを使え」と主張している
わけでもありませんし、スタックを否定しているのでもありません。

･･･とかわざ言っとかないと、また>>488が勘違いするからな（藁

>>493
あらためてその議論を読み返してみたけど、やっぱり全然議論が
噛み合ってないね。Sugiharaにも問題があるだろうけど、前田サン
にも問題ありだ（議論の方法がね）。

すげー気持ちわるい。隔靴掻痒。

さてと、そろそろ帰るか（藁
488よ、何か書き込むのならまず、

>>490
>で、間違ってると主張するんだね？(Yes/No)

の答えから頼むぞ。俺はまずそれが知りたいんだ。

>>498
>「ペアにして使うように気をつければリークが減る」
って当然「真」でしょ。自明。
だってmalloc()に対応するfree()がなければexit-on-freeするときでない限り絶対リークするでしょ?
なんたってfree()しないんだから。
気を使おうが使うまいがしなければリークが増えますね。確実に。

>>497
知ったか厨房に対しては前田氏の方法で知ったかぶりを
徐々に第三者に対して明らかにするのは有効では？

知ったか本人に自覚は促せなくても第三者はそれによって
「あっこいつ知ったかだ。気ぃつけよ」と分かって有意義じゃないか。

…粘着君に似てるな、君。
快・不快原則で議論を裁こうとしてる。

ちっとも自明じゃないよ。>>499
そもそも「リーク」とはどういう状態を指して言っているのかが
人と場合によってまちまちだし、それによって答えも変わるし、
また『リーク』を減らすのがメリットにならない場合もある…
という議論は fj でとっくの昔に出てるんだぜ。
それをここでもう一回繰り返せってのかい？

>>501
そうそう。そんなかんじ。

>「ペアにして使うように気をつければリークが減る」
だから何ナノ?っていいたかった。

ついでに、ペアってどういうことさ？
前からずっと疑問に思ってた。どっかで定義されてたっけ?
malloc()とfree()が1対1対応させるということ?1対多?多対1?多対多?
スコープは?ブロック?関数?1つのファイル内?(C++なら)クラス内?プログラム全体?

>>502
>malloc()とfree()が1対1対応させる
malloc()とfree()を1対1対応させる

スコープにはモジュールを追加しといてくれ。すまそ。

>>496
全然違い分かりませんわ。
ほんとにfj読んだんかいな。

>>501
>そもそも「リーク」とはどういう状態を指して言っているのかが
>人と場合によってまちまちだし

えと、ちょっとお尋ねします。
メモリリークってそんなにあやふやな言葉なんですか？
僕は「システムに返却されなかったメモリ」のことだと思ってたんですが、何か他に
「メモリリーク」と呼ばれるものがあるんでしょうか？
横入りｽﾏｿ

リークってなあに？

>>502
>ついでに、ペアってどういうことさ？
>前からずっと疑問に思ってた。どっかで定義されてたっけ?
>malloc()とfree()が1対1対応させるということ?1対多?多対1?多対多?

えーと、このスレもfjもまじめに読んでないからはずしてるかもしれないけど、
ペアって1対1以外に解釈のしようがないような気がするんですが・・・。
そういうことで無い？

>>506
えーと、これは僕に対する質問ですか？

>>508
そういうわけではないです。リークといっても階層ごとに指すもの
が違うと思うが。

リークってこの議論での場合、
「ある時点でもうfree()出来ないメモリ、
つまり、ローカル、グローバルのどの変数からも参照されてないメモリ」
あたりでいいんじゃない？
それ以外のリークの意味を想定して話してる人っているのかな?

で、最終的なリークの量の上限を求めることが出来て、
なおかつその量が許容範囲内(数メガとか)なら別にfree()しなくてもいいジャン、
ってのが所謂「free()不要派」の主張じゃないかな?

対して、
「ちゃんとfree()しないとおばかプログラマ(自分含む)がバグ作りこんじゃうだろ」
ってのがfree()必要派の主張だと思ふ。

全然かみ合ってませんね(わら

上限を保証するため面倒な見積もりするくらいなら
freeしたほうが楽だと考えてしまう怠け者な俺

組込のようなサイクリックプロセスではリークを許すと上限は必ず無限大になる。

ヒープを自分で管理する。

>>512
そうだね。
そういうときはfree()しよう。
なんて単純なんだ！

>>511
それじゃ箱っちといっしょだよ。

１ malloc されたメモリ
→ 所有権は malloc、状態は使用中

２ malloc された後、free されたメモリ
→ 所有権は malloc のまま。状態は未使用

で、再び malloc が行われた場合は、２のメモリを優先的に割り当てるってのが
一般的な仕様ですよね。

んで、リークってのにも２つあって、例えばループの中で malloc して free
しなかったら、そのプロセスの使用メモリ量がどんどん肥大していく。それが
プロセス内でのメモリリークで、これは free することで防げる。

もう一つが、プロセスが終了した時に、malloc 所有になってたメモリが開放
されないという、システムレベルでのリーク。
「exit の前でも free しろ」ってのは後者を意識しての事だろうけど、これは
free で防げるたぐいのものではない。
free した時点で malloc 所有のメモリが OS に返る実装なら防げるが、Cの規格
ではそういう実装は要請されていないし、動作速度の点で実際そうなっていない
実装がほとんど。

よって、必要な free は省いてはいけないが、exit の直前の free は必要な
free ではない。

そういうことでしょ？

１ malloc されたメモリ
→ 所有権は malloc、状態は使用中

２ malloc された後、free されたメモリ
→ 所有権は malloc のまま。状態は未使用

で、再び malloc が行われた場合は、２のメモリを優先的に割り当てるってのが
一般的な仕様ですよね。

んで、リークってのにも２つあって、例えばループの中で malloc して free
しなかったら、そのプロセスの使用メモリ量がどんどん肥大していく。それが
プロセス内でのメモリリークで、これは free することで防げる。

もう一つが、プロセスが終了した時に、malloc 所有になってたメモリが開放
されないという、システムレベルでのリーク。
「exit の前でも free しろ」ってのは後者を意識しての事だろうけど、これは
free で防げるたぐいのものではない。
free した時点で malloc 所有のメモリが OS に返る実装なら防げるが、Cの規格
ではそういう実装は要請されていないし、動作速度の点で実際そうなっていない
実装がほとんど。

よって、必要な free は省いてはいけないが、exit の直前の free は必要な
free ではない。

そういうことでしょ？

ちがう

組込のようなサイクリックプロセスではリークを許すと上限は必ず無限大になる。

おまえのあたまのなかではな

リークってこの議論での場合、
「ある時点でもうfree()出来ないメモリ、
つまり、ローカル、グローバルのどの変数からも参照されてないメモリ」
あたりでいいんじゃない？
それ以外のリークの意味を想定して話してる人っているのかな?

で、最終的なリークの量の上限を求めることが出来て、
なおかつその量が許容範囲内(数メガとか)なら別にfree()しなくてもいいジャン、
ってのが所謂「free()不要派」の主張じゃないかな?

対して、
「ちゃんとfree()しないとおばかプログラマ(自分含む)がバグ作りこんじゃうだろ」
ってのがfree()必要派の主張だと思ふ。

全然かみ合ってませんね(わら

わら

われらがゲイツ様が作られた .NET は、素晴らしいに
違いありません。
きっと世界を席巻するでしょう。

519 名前： Gates万歳！ 投稿日： 2001/06/14(木) 23:00
われらがゲイツ様が作られた .NET は、素晴らしいに
違いありません。
きっと世界を席巻するでしょう。

こいつ馬鹿？

>>520
　冗談くらい分かってやれよ

ゲイツ様のガベージコレクタは世界最強に違いありません。

うーむ、つまらん。
もう、よそう。
新しいねたになればと思ったが、資料がなかった。

ハァ？ＭＡＬＬＯＣなんてもう終わったんだよ？newとdeleteあればいいんだよボケども。俺様に南下もんく案の火？

522 名前： Gates万歳！ 投稿日： 2001/06/14(木) 23:06
ゲイツ様のガベージコレクタは世界最強に違いありません。

うーむ、つまらん。
もう、よそう。
新しいねたになればと思ったが、資料がなかった。


馬鹿は馬鹿だからな

>>522-524
ネタは sage でな。

ちなみに、まったく面白くないぞ。

つーかさー「mallocしたら必ずfree」を論破するには
くだらん主張をを延々とやってないで
freeしたら破綻するような実例をたった一つageればすむことなんじゃないの？
なんかageてみろや

>>516
exit()後のリークはこの議論には関係ないと思うけど?
fjでもちゃんとしたmalloc(), free()ならexit()してもリークしないってのは合意されてるよね?
で、いまfjでやってるのが、「free()したほうがデバッグしやすくリークが減るので、必要」っていうけど、ほんとにそうなの?ってこと。

>>526
>「mallocしたら必ずfree」
誰がそんなこといってるの?(藁

>「mallocしたら必ずfree」
誰がそんなこといってるの?(藁

盲目？

ハァ？ＭＡＬＬＯＣなんてもう終わったんだよ？newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火？

ハァ？ＭＡＬＬＯＣなんてもう終わったんだよ？newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火？

ハァ？ＭＡＬＬＯＣなんてもう終わったんだよ？newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火？

いつまで井戸端おしゃべりしてんだよ、ヴァカども（ｗ

ＶＢならメモリリークなんて気にする必要ねーーんだよ、ヴァカども！（ｗ

かなり、話しの本質をずばりと突いていると思います。
それでは、結論としてはそのようなDQN依頼者は無視するべきなんでしょうか？
きちんと説明して、納得させて、そのような会社から500万前後の依頼料を
取れるのであれば、その話しは良い商談となったのではないかと思います。

これからは、このような零細企業でもちょっとしたソフトを導入したいと
言ってくるわけですから、そのような依頼者をどうやって扱うべきかという
問題も更に増えてくるんじゃないですか？かなり、話しの本質をずばりと突いていると思います。
それでは、結論としてはそのようなDQN依頼者は無視するべきなんでしょうか？
きちんと説明して、納得させて、そのような会社から500万前後の依頼料を
取れるのであれば、その話しは良い商談となったのではないかと思います。

これからは、このような零細企業でもちょっとしたソフトを導入したいと
言ってくるわけですから、そのような依頼者をどうやって扱うべきかという
問題も更に増えてくるんじゃないですか？

>>532
金のためなら、ケツの穴貸しますさん登場！（藁

>>505
言いたいことは >>515 がだいたい言ってくれているが…
少なくともこの議論では以下の三つの違いくらいを意識してないと話が噛み合わないことがあるぞ、と言いたい。

(a) mallocしたメモリが、どの変数からも参照されていない状態になってしまった
(b) mallocしたメモリを単にfreeしていないだけの状態(で、そのままexitする)
(c) exitした後で、OSのリソースが解放されないままの状態になっている

(a)は普通はバグ(意図していない)だろうが、(b)は設計意図としてそうしている場合もある。
>>499 が言ってることは、(b)を「リーク」と呼べば正しいかも知れないが、
(a)や(b)の意味でのリークが起こっても、(c)の意味でのリークは発生しない。
少なくとも ANSI C の malloc/freeがまともに動く近代的なOSの上ではね。

>>527 は(c)は関係ないだろ、と言ってるが、fjで最初の頃「原則free」の理由として
(c)のリークが発生する環境があるからだ、という意味の主張をしていたのが
他ならぬ箱氏だったはず。

今は違うのはその通りだけど、どうもここにはfjを読み返したがらない輩が
いるようなのでな。

>>526
> freeしたら破綻するような実例をたった一つageればすむことなんじゃないの？
だろ? だろ? 普通そう思うよな。
でもそれをいくら挙げても、納得しないで延々ゴネてる奴がいたから
今のfjのスレッドがあるのさ。

とりあえず、
Windows NTではちゃんと free()しないと、プログラムが終了しても
メモリはぎりぎりまで開放されません。「ぎりぎりまで」ってのは、
「必要とされるまで」という意味で一見あたりまえで無害に見えますが、
ほかプログラムの起動時のコストやシステム全体のパフォーマンスから
見ると好ましくありません。

>>534
(b)ってリークって言うのかな？(将来的にリークするメモリとか言う感じだっけ?)
「exit()するということは、main()とグローバル(プログラム全体)スコープからぬけた」
とみなせば、(b)のメモリ、つまりexit()直前に残っていたメモリは(a)の意味でリークしたとみなせない?
強引かな?
(c)はすでにこの議論には関係ないとして(でいいよね?)、
そうすればリークの意味が(a)に統一されるよね。

俺っちが考えてたリークの種類ってのは、
(1) プログラムの実行に悪影響を及ぼすリーク(というかリークさせるコード)
(2) 悪影響を及ぼさないリーク
という感じで、まぁ、(a)(b)にだいたい対応してるけど、(a)でも影響なければ(2)ということ。
>>510 で書いたのもそういうことね。

そう考えればずいぶん単純な話にならない?
もしmain()をモジュール化して再利用したいならfree()が必要という箱っちの主張も妥当
(main()をモジュールとしてってのが最悪だが)。
悪影響を及ぼさないメモリはfree()しなくていいんだからfree-on-exitも妥当。

まぁ、結局>>515 の「必要な free は省いてはいけないが」ってことばに結論は集約されてるんだけどね。
問題はfree()するかしないかじゃなくて、どうfree()するかなんだから。
もちろんこれは、今の議題とはべつの議論だけどさ。

>>527
長すぎたか…

どっちにしろ、いまfjでやってるのは、互いのレトリカルな表現が気に入らないから
自分の気に入ってる表現に直せってことなんだよね。偏見入ってる意見かもしれんが。
ほとんどの事項で合意は成り立ってるんじゃないかな?

>>536
それって本当?開放されないってどのレベルで?
どういう仕組みになってるんだろ?＞NTのメモリ管理
いや、本当にしらないので。

>>507
ペアだったら1対1だけど、対称とか、fjでは対応ということばも使ってたよね。
だからどれかなと。
それと、ペアにするのはどのスコープ内でなのだろう。

>>526
> freeしたら破綻するような実例をたった一つageればすむことなんじゃないの？
fjではスラッシングがageられていた

# fj読めよ

それってexit直前にfreeすると何か変わるの？
(変わるならNTって逝かれてる。)

>>542
変わるのはmallocでなく、「なんちゃらalloc」という関数。
少なくとも新K&Rで掲載しているmallocのソースを見る限り
変わらないと判断するのが妥当。brkという関数に対になる
関数がないから。
”終了時にリークする関数がmallocという名前で存在し得る”
という前提が非現実的。

>>537
> (main()をモジュールとしてってのが最悪だが)。
同意。で、そこら辺のセンスの怪しさが箱氏の論全体の怪しさに繋がる。

>>512
> 組込のようなサイクリックプロセスでは
> リークを許すと上限は必ず無限大になる。

512 の組み込みはトランプの城のような安定性。

組み込みのようなプログラムでこそレイヤで「防壁」を
設けることが重要なんじゃないかって同スレで Kono 氏が言ってたよ〜
資源管理の防壁単位でリセットかませばリーク消し飛ぶじゃん。
「必ず」のわけないじゃん。

# やはり声を大にして言わなきゃならんな。fj 読めや。
# 読まない奴に限って free なのは
# 勉強しないプログラマ＝free 派だとの傍証のような〜（煽り煽り）

> 大域空間って、グローバル変数のことだったんですね。
> てっきりヒープ（malloc()で取得できる空間）だと思ってました。
> ＃これからはそのように理解いたします。
だれかこいつに「逝ってよし」って言ってやれよ。
# だんだんウザイよりも哀れになってきた．．．

>>545
># 勉強しないプログラマ＝free 派だとの傍証のような〜（煽り煽り）
設計できないプログラマ＝free必要派じゃなかったっけ？(さらに煽り

>>546
ここ数日 fj.comp.lang.c 読んでいないけど、その発言って例の Sugihara ？
あの馬鹿なら言いそう。っていうか、あいつ完全に初心者だろ。C 言語歴 1 年
以内くらいの。藁

mallocとヒープが関係していることは学習したようですが?

>>549
でもグローバルという言葉の意味までは考えなかったらしい（藁
次は「えっ関数もグローバルなんですか」とか言い出すぜ、きっと。

>>546
おいらそれみてHAGESHIKUﾜﾗﾀよ。

どんなツッコミがくるのか今から楽しみ。

>>526
＞ つーかさー「mallocしたら必ずfree」を論破するには
＞ くだらん主張をを延々とやってないで
＞ freeしたら破綻するような実例をたった一つageればすむことなんじゃないの？

「free しなくても破綻しない実例」の間違いでは？

> 「free しなくても破綻しない実例」の間違いでは？

Compiler の構文解析木とか。

メモリリーク
「動的メモリ割り当てシステムにおいて、利用できないメモリ領域が生じること。そのような領域が徐々に増えていくこと。またその領域のこと。
メモリ割り当てシステムの管理下からメモリが漏れ出して、利用可能なメモリ領域が減ってしまうように見えるのでこの名がある。
（例）
・プログラム内におけるメモリリーク
そのプログラムで利用しておらず、将来再利用もできないメモリ領域が生じること。
・OSにおけるメモリリーク
どのプロセスも利用しておらず、将来プロセスに割り当てることもできないメモリ領域が生じること。」

>>552
「free しなくても破綻しない実例」なんか出して何か意味あんの？

んで、「Compiler の構文解析木」という例が出たけど、それで一体
なにが導き出せるんだ？

# 勉強しないプログラマ＝free 派だとの傍証のような〜（煽り煽り）
>>めんどうだからフリー派でいいや

>>555
１ 必要な free を省けば、当然問題を起こす。
２ 不必要な free（書いてあっても問題は起こさない）は省いてもよい。
３ 余計な free は、当然問題を起こす。
このうち３は、今の議論では問題外。

で、「mallocしたら必ずfreeしろ」ってのは、２の不必要な free も
省かずに書けって言ってるわけだから、「free しなくても破綻しない
実例」は反例になる。
「freeしたら破綻するような実例」こそ、この議論にはまるで関係ないと
おもわれ。

＃ もっとも、納得するかどうかは別問題で、そういう説明をされても「うちの
＃ 環境では…」と暴れだしたのが某箱氏。

はぁ？誰も「mallocしたら必ずfreeしろ」なんて主張してねーぞ。

つーか、今だにそんな先入観持ってた奴がいたのか。

>>558
>はぁ？誰も「mallocしたら必ずfreeしろ」なんて主張してねーぞ。

ああ、そうか。
んじゃ

で、「mallocしたら必ずfree」ってのは、２の不必要な free も省かずに
書くって言ってるわけだから、「free しなくても破綻しない実例」は反例になる。

に修正。

>>557
でもそんな議論はとっくに終わっていて今は、
「free()したほうが、
(1) debugのために便利
(2) バグ(リーク)が減る
(3) あとでモジュール化するときに不便
だから、原則?free()したほうがコストが下がる。」
とかいう主張に、
「まぁ、そういうこともあるだろうけど、一般的には違うでしょ?」
とかやってるわけですよ。

そういえば
>(2) バグ(リーク)が減る
っていってたひとはどこに？

>>561
片岡モドキか？ fj読み直してんじゃねーの？（藁

>>557 をー、裏を返せばそういう受け取り方もできるのカー、としばし感心
この人は論理学がすごく得意なのかヒネクレてるかのどっちかだろう（アヲリ）

もともとの fj の議論はまさに３も重要な論点だったのだよ。
「余計なfreeなどない！freeして問題が起きるのは設計が悪いからだ」
みたいなことを言ってた人もいたしね。だからfreeしたら破綻する例として、
コンパイラの構文木やスラッシングの話がfjで出たのさ。

>>557
省いても良いfreeを省いても当然問題は生じないのだが（ｗ

free派は「そういうfreeも書いとくと、たまぁに良いことがあり、コストとベネフィットを平均するとプラスである」と主張していると思われ。

なので１つや２つ「良いことがない」例を挙げても反論にならないのでは。

free 派の心情が 564 が説明してるようなものだとして、
するとやっぱりそれは宗教なんじゃなかろーか。

たまぁに良い事がありってあたりがなんだか
カーゴ・カルトの信者みたいだよ。

>>563
いや、別に揚げ足を取ってるつもりはなくて、ただ素直にそう思っただけっす。
根がヒネクレモノなんですかネ（＾＾；

>>564
御意。たしかにその通りですな。

ただし、納得するしないという点では、１つ２つ「freeしたら破綻するような実例」
出しても、「そういう例外はあるけど、原則は…」とやはり説得不能とおもわれ

ヒープソートって malloc 使うからそういう名前なんですよね？

Kono の言うことを無批判に受け入れる人もいるんだね。

気になったのですが、
最近のＷｉｎｄｏｗｓって解放忘れたメモリーも解放してくれるのですか？

今まで信用してなかったから　全部free してましたけど．．．。
JAVAと同じように OS側がメモリー解放をしっかりしてくれるって思うと
すこし気が楽に組めそうです。

>>568
まず568さんに「レイヤ作って防壁」への批判をお願い致します。
無批判に〜などとそしるのであれば可能なはず。

>>570
レイヤはすでにmallocで分かれているので必要ありません。

>>569
exitで解放できないならfreeでも解放できないはず、ってのがとっくにfjで出てる。
(ただしmalloc()でなく なんちゃらAlloc()みたいなのは別。)
fj読めや。

>>566
同意。いずれにせよ1つの反例で片付く問題ではない。
おいら的には「省いてよいfreeは省いてよいに決まってんじゃん！」で終わってるのだが。

>「省いてよいfreeは省いてよいに決まってんじゃん！」
これって金取ってる複数人プロジェクトでやってるの？

ついでにどんな分野のアプリで何人月くらいの規模なの？

>>574-575
何で技術的な理由で満足できずに、規模とか金に拘るかな。技術的な
正否を自分で判断できないのか？

>>576
よ〜するに、この手法は規模とか金とかに絡んだ分野での
実績がないって事？
単にこの手法の実績の有無しが聞きたいだけなんだけど。

実績のないぼ〜やには聞いてないよ。

>>577
仕事内容の詳細を、外に出せるとは限らないでしょうが。

実績の有り無しだけ言えば、私のところでは「有り」なんだが、それを聞い
てどうするよ？　実績があっても、腐った開発手法なんていくらでもある。
最後の拠り所は、技術的な正否だけでしょ。

> 実績のないぼ〜やには聞いてないよ。
現役の職業プログラマですが、何か？

現役の職業プログラマだって腐った奴はいくらでも居る。

>仕事内容の詳細を、外に出せるとは限らないでしょうが。
詳細には興味ないよ。この手法の適用可能なおおまかな規模と分野を知りたいだけ。

>最後の拠り所は、技術的な正否だけでしょ。
そりゃ違うね。文法的仕様的にあっているかどうかと言うことと
まともな開発に耐えうるかどうかということは全く別次元の話だよ。

>実績の有り無しだけ言えば、
実績「だけ」を聞いてるわけではないよ。聞きたいのは以下の点。
・複数人で開発する場合にコンセンサスを得られるか？
・規模がある程度大きくなった場合破綻しないか？
・Bounds Checketのようなツールの動作を阻害しないか？

想像するに573,578の言う実績ってこんなものじゃない？
・開発人数：一人(メンテも自分でやる)
・規模：千行以下（良くて数千行以下）
・バグ検出ツールの併用：無し

そだね。
そもそも組込みとかだったら「省略可能なfree」が存在しないことの方が多い気がする。

つーか、C++のnew/deleteはセットにしないといけないし、
資源豊富な環境のCなら、GCでも使った方がよっぽどいいし、
タイト環境のCなら、malloc/freeという仕組み自体使うのを
考慮しなきゃいけない(独自のアロケータとか)。
　そんなわけで、この話は終わってると思うが。

>>580
> この手法の適用可能なおおまかな規模と分野を知りたいだけ。
それを判断するための材料は既にこのスレッドと fj の議論で出尽くし
てると思いますが、何が不足しているとお考えで？

>それを判断するための材料
だから判断「材料」を知りたいんじゃなくって実績が知りたいんだってば。
どうも妄想だけで議論が進んでるような気がするので。

省いてよいfreeを省くのに理由はいらない
省いてよいfreeを書くのには理由がいる

実績を挙げて説明すべきなのは書く側だと思われ

>>585
ﾃﾞﾑﾊﾟ君？

long int i;
long i;

省いてよいintを省くのに理由はいらない
省いてよいintを書くのには理由がいる

と思うか？

>>584
> どうも妄想だけで議論が進んでるような気がするので。
気のせい。スレッド読み返しましょう。

>>587
気のせいなら>580に答えてよ。
実績のない妄想君じゃないんならさ。

>>588
ウチでは実績があるって書いたじゃない。匿名掲示板で、詳細を伏せ
て書いたことに対して

「信用できない、どうせ数千行程度、一人で保守してる子供だましの
プログラム開発なんでしょ」

と返されたら、それ以上言うべきことは何もありませんな。あとは、ここ
のスレッド読み返してださい。書くべきことは、もう書いたから。

>>580
>・複数人で開発する場合にコンセンサスを得られるか？
これがfjとかでいわれてる、いわゆる「お寒い状況」ってやつですか？
でも現実はそんなもんかもね。だから宗教だって言われるんだろうけど。

>・規模がある程度大きくなった場合破綻しないか？
しないよ。

>・Bounds Checketのようなツールの動作を阻害しないか？
これがそんなに大事ならfree()してれば？
「チェックして大丈夫だった〜やった〜」とかいう気休めがそんなにほしいのかね？

とかかかれていたような気がす

Boudns Checkerってメモリ境界を越えたアクセスとかを検出するツールのことだから
この議論には関係ないんじゃ、と思ったら
http://www.numega.com/devcenter/bc.shtml
これのことなのね。なるほど。

もとの話題がfree-on-exitなのになんで「組み込み」とか「ずっと走るプログラム」とかdeleteとか言うやつがいるんだろ。fj全然読まずに脊髄反射してるのが一目瞭然。

規模？ 何人のプロジェクトだろうと、アセンブラのシンボル表やコンパイラの構文木をexit前にいちいちfreeしてたら即クビでしょ。

省いて良いfreeなら省いて良いに決まってるだロー
「省いて良いfreeは省いちゃダメ」って見るからに矛盾じゃん（ｗ
あったま腐ってんじゃないの？

>>593
「free必要派」は、「省いていいfreeなどない！（ただし例外アリ）」といいたいのではないかと。
その理由が>>580

>>592
>脊髄反射してるのが一目瞭然。
同意。特にdeleteを持ち出すやつは論外だね。

だいたい「組み込み」とか「ずっと走るプログラム」(終了しないプログラム)で
ちゃんとfreeしないといけないのは当然だろ(もちろん"例外"のmallocもあるよ)。
で、ちゃんとfreeするために独自のアロケータを作ったりGC使ったりしろって言われてんだろ?

>>580
> ・Bounds Checketのようなツールの動作を阻害しないか？
もちろん free() しないということは、その手のツールで「終了時に解放
されていないリソース一覧」を表示させると、そこに表示が出ることに
なる。じゃあ逆に、表示が出ないことにどれほどの意味がある？

この手のツールは、「リークがある」ことは指摘できても「リークがない」
ことは保証できない。だから開発時には、いろいろテストを用意して、
それぞれのテストで

　プログラマが予期したとおりにリソースが確保／解放されている

ことを確認していく。各テストはプログラム終了時に行うわけではな
いから、当然のことながら解放されていないリソースも存在する状
態で行われる。

ソフトウェアのテストをしたことがあるなら、プログラマが意図的にリ
ソースを解放しないことで

　「ツールの動作が阻害される」

はずがないことは明白なんだが。そんなツールは、あったとしても実
用にならないから。

>>595
exit-on-freeするやつらはきっとプログラム終了時のチェックしかしないんだよ

糞スレにつきage

fjに片岡再登場！

>自分が作るプログラムの外にあるものって何でしょうかね。
>OS？　コンパイラ？
>
>ネットワーク越しの端末に「しばらくお待ちください」と表示したまま
>exit や異常終了するとお客様からファイヤーが来るとも来ないとも、
>確かに規格書には書いてありませんけどね。
>
>責任範囲って何？　あんたらの仕事には存在しない？？
>そりゃ尻拭いって場面は現実問題としてはありますけど、
>そんなの込みで主張されていますかね、本当に。

今度は最初からやけにテンション高い。
書いてることは相変わらずキティ外だが。
free-on-exitが是か非かの話が、いつのまにかexitが是か非かに化けてるし（ｗ

> 片岡再登場！
Ｋ山と一瞬見間違った。

# Ｇ神も再登場したらあと半年は続きそうだ。

片岡か。こいつ確か fj の別のグループでスピード違反していると堂々と
語っていなかったっけ。んで周りにドキュソ扱いされていた。

そんなこと公の場で発言していい事じゃないよね。

G神はなぁ…。
まともに仕事を仕上げた事が無い。
能書き垂れまくって仕事をもらい、
言い訳垂れまくってほっぽり出す。
その繰り返し。
もう誰も信用する人がいなくなったから米国へ移住した。

>>601
例え本当でも、そゆこと書くのは良くないと思うぞ。

こんにちは、鶴田(SYN)です。

各自の主張はもう十分に理解されていると思います。お互い譲れな
い部分はあると思いますが、これ以上続けてもネタになるだけで、
双方に何のメリットもない気がしてきました。

まだ、フォローしたい人もいるだろうし、私もしてしまうかもしれ
ませんが、これは見ておいたほうが良いと思います(藁)。

プログラマー＠2ch掲示板
「始まった！malloc and free - fj.comp.lang.c」

http://mentai.2ch.net/test/read.cgi?bbs=prog&key=981051921

面白かったです。

>>604
消防の読後感想文レベルだな（ｗ

すぎうらさん、箱さん、海亀さん、文平さんで
オールスター戦をキボンヌ。

>>603-604
何をいまさら・・・

文平さんかー、なんか記憶の底に澱もののように沈んでいた名前だ。
なにしたひとかどうしても思いだせん。

>>608
http://mentai.2ch.net/isp/kako/950/950464541.html

>>609
さんくす。おかげさまで思い出すことができました。

いやー一年なんてはやいものだね。

おかげさまで活発な議論もようやく収束しました。
みなさんお疲れさまでした。

せっかくなので議論の結果をまとめておきます。

・malloc, freeは「必ず」対で使用する。
・（ヒープの断片化などで）malloc, freeを直接使用するのが好ましくない場合は
　自前のヒープ管理ルーチンでを導入する。
・GCのあるJavaの導入を検討する。

例外
以下のケースではfreeしない事を検討してもよいでしょう
・社内のコンセンサスが不要なくらい孤独な場合。
・"free(p);"を省くことで全体のタイプ効率の向上が望める程度にソースが短い場合。
・今後自分でメンテナンスしないことがはっきりしている場合。

Ｃを勉強中の方（特に学生さん）は
この議論の流れと結論をじっくり吟味してください。
そしてfree不要派の反面教師ぶりをしっかりと目に焼き付けてください。
みなさんが今後ソフトウェア開発業界で活躍する上で、
このスレッドで得られた知見が貴重な糧となることでしょう。

葬送

なんかさ2chの議論で「必要なのにsageしない厨房」が増えたような気がしない？
>>1-999とかもわかったようなこと書いてるけど、微妙にはずしてるし。

>>611
つまらんネタ。
「free不要派」ってとこだけちょっとワラタ。なんだよそれ。

さっそく一匹釣れました（藁

>>611 >>614
ネタとしては及第点だが（優／良／可／不可で可）、sage てないのが
減点。精進して下さい。

おかげさまで活発な議論もようやく収束しました。
みなさんお疲れさまでした。

せっかくなので議論の結果をまとめておきます。

・チンコ, マンコは「必ず」対で使用する。
・（包茎の皮の断片化などで）チンコ, マンコを直接使用するのが好ましくない場合は
　コンドームを導入する。
・経口避妊薬（ピル）の導入を検討する。

例外
以下のケースでは避妊しない事を検討してもよいでしょう
・社内で孤独に陥った末の強姦の場合。
・避妊を省いても、全然膣に届かない程にチンコが短い場合。
・今後自分で子育てしないことがはっきりしている場合。

Ｃを勉強中の方（セクースの意味だｺﾞﾙｧｰ）は
この議論の流れと結論をじっくり吟味してください。
そして避妊不要派の右反りチンコぶりをしっかりと目に焼き付けてください。
みなさんが今後セクース業界で活躍する上で、
このスレッドで得られたエロ知見が貴重な種（精子のことだｺﾞﾙｧｰ）となることでしょう。

イッテヨシ

fjの連中ってどうしてこんな
基地外ばっかなんだろ

　　∧＿∧　　 ／￣￣￣￣￣￣￣￣￣￣￣
　（　´∀｀） ＜ 　オマエモナー
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜ ｜ ｜
　（_＿）＿）

形式論理もよう把握できんヴォケがあがいても意味ねーわ

>>617-618
おお！すげえ久しぶりに典型的な２ちゃんねるのレスを見たよ。

とりあえずこのスレ上げます（　´∀｀）

なんか終わったようだね…。

>さらに単純な命題に分析します．
>
>P1 :「free()絶対する派」はコストバランスを全く考えていない．
>P2 :「原則free()」を唱えている人はコストバランスを全く考えていない．
>Q1 : 「free()絶対する派」はコストバランスを考えていても原理原則より
> 下に見ている．
>Q2 : 「原則free()」を唱えている人はコストバランスを考えていても原理
> 原則より下に見ている．
>
>上と同様に（今度は「述語の共通化」により）P は「P1 or P2」と同じ意味で，
>Q は 「Q1 or Q2」と同じ意味になります．
誰か命題のorの取り方教えてください。

>>622
また一年後ぐらいに再開する、に一票。

>>624
このスレがなかなか終わらないに一票かな。

忘れた頃にmalloc&free

#define memalloc(x) malloc(x)
#define memfree(x) free(x)
にすればmallocもfreeも使わなくてヨシ。
っていうか皮被りじゃない俺逝ってよしなら逝ってくる。

#define freeallonexit()
良ければ使ってください。

片岡いまだ死なず

>> したがって、 プロセス終了時にOSが(プロセス自身の解放によって)
>> 処理される事を期待する以外にないことを意味します。
>
>同じことですね。
>「そのOS」がプロセスを正常に解体できること　＊だけ＊　は
>Cで書く限り処理系に依存せず保証されているとお考えですか。
>
>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。
>
>どこまでが自分の落ち度かを切り分ける能力は
>アマとプロの違いの１つとも思えます。

はぁ〜あ、いまさら何いってんだか。free-on-exitしてもしなくても関係ないじゃん。
free-on-exitしてもしなくてもOSがダメならリークするし、まともなOSならリークしない。
こいつもSugiharaと同じレベルだな。態度がでかいぶんタチが悪い。

> どこまでが自分の落ち度かを切り分ける能力は
> アマとプロの違いの１つとも思えます。

assert()を実行したときに条件が充たされていないとプログラムは
終了しますが、OSやライブラリによるメモリ領域の解放が行われな
いとすると、そのときまでにfree()されていなかったメモリブロッ
クの領域はリークすることになります。
こういう場合は

(1) assert()を使ったのがプログラマの落度である。
(2) assert()が実行される前にすべてのメモリブロックをfree()す
るようにしておかなかったことがプログラマの落度である。

のどちらになるのでしょうか。

--

assert を使っているぐらいなら恐らくテスト段階だと思われるので、
別にメモリリークがあってもいいような気がするのは自分だけ?

それとも assert って release 版にも入っているもんなのかな?

いまだにゴチャゴチャ言ってるヤツは、下落したメモリすら買えない貧乏人。
と煽ってみる。

release版でassert()を外す...
そゆのは「陸上で救命胴衣を着て練習し、沖に出るときに救命胴衣を外す
ようなもの」と言ったエライ人がいるね。

>>630
>別にメモリリークがあってもいいような気がするのは自分だけ?
assert()までにfree()されていないメモリブロックって
かなりでかいだろうから、そのうち仮想メモリまで使いきっちゃうと
思うぞ。

>>632
assert ってデバッグ時以外にも使うものなのか…。
おいら知らなかったよ…。

> 「そのOS」がプロセスを正常に解体できること　＊だけ＊　は
> Cで書く限り処理系に依存せず保証されているとお考えですか。

この部分を

コンパイラがwhile文を正しく扱えることはCで書く限り処理系に依存せずに
保証されているとお考えですか。

とかえてみる。

>>635
>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。

これは

>「そのOS」がプロセスを正常に解体できるかどうかに係わらず自分は
>「そのOS」がプロセスを正常に解体できることを当てにしないプログ
>ラムを書くべきと私は考えますがね。

とゆうことだから、635のように換えると

>コンパイラがwhileを正しく扱えるかどうかに係わらず自分はコンパ
>イラがwhileを正しく扱えることを当てにしないプログラムを書くべ
>きだと私は考えますがね。

となるね。

>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。
を、

インポートしたDLLが壊れているかどうかに関わらず
自分はそのDLLが正しく使えることを当てにしない
プログラムを書くべきだと私は考えますがね。

とも変えてみる。

「外にあるものが正しいかどうかに係わらず」
なんじゃこれ。オカルトプログラマか。

薬効成分がなくなっても効き続ける薬なんて
ネタがオカルトサイエンスにあるけど、
それと似たようなものだろうか。

コンピュータの電源が落ちていても
動くべきプログラムとか。（ﾟдﾟ；；；ｺﾜﾋｰ

↑つ，つまらなすぎ・・・・・

時として、バグのある環境で動かすためにアプリ側で対処する必要があるのは確かなのだが、
バグのある環境を事前に想定してプログラムを組むというのはやはり無駄な労力だと思われ。

>>639
悪かった。連日寝不足なんだよ。

またも片岡が前回の結論を全く参照せずループ状態に陥ってる
ところをみると、freeをわめく連中のやってるのは議論ではなく
プロパガンダって事だね。

世の中暇人が多いんですね。＜fj

箱登場。

週に一回の発症か。

>> “Subject: Re: free-on-exit and its practical value”をお忘れで
>> すか。
> malloc() ライブラリに対する私のインターフェースには、プログラム終了時など
>と言う条件は入っていないと言っているのですけど、理解できませんか ?
ワラタ。

箱氏、なんだかだ言って結合が密になってるじゃん。
それで疎になると称するのは技術者としてどうよ？

あの議論に参加している人ほとんどが技術者として失格。

理論こねくり回してる奴って二流多いよな。
コーディング規約守れとか、姑かっつーの。
プログラマならコードで語れ。

>>647-648
なんかまるでGonzoな人たちみたいに見えるだよ（藁
http://namazu.org/~satoru/misc/gonzo.html

マッチョと同義でしたっけ？ ＜ゴンゾ
ページに書いてある例は「理論や大局観の欠落したスタンス」みたいですが。
「ある意味、典型的なＣプログラマ」なんて揶揄もあったな。

で、「とりあえずコード書いとけ！」も「とりあえず free 置いとけ！」も同じと。

>> よって、まともな環境では、mallocしたメモリを
>> freeしないで終了しても差し支えない。
>
>規格制定以前の、それこそ互換性クソっ食らえで作られた
>既存のコードが擁護されているだけです。
>
>今日でも、互換性クソっ食らえで書くコードになら
>よい考えかも知れません。
>
># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか？

片岡：

>> よって、まともな環境では、mallocしたメモリを
>> freeしないで終了しても差し支えない。
>
>規格制定以前の、それこそ互換性クソっ食らえで作られた
>既存のコードが擁護されているだけです。
>
>今日でも、互換性クソっ食らえで書くコードになら
>よい考えかも知れません。
>
># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか？

誰かこのKitty飼いの言ってること通訳して。
互換性を前提にするならstaticがゼロクリアされてると
仮定していいんじゃないの？

片岡は、
・freeしてからexitしてもメモリリークが起きることを仮定する
だけじゃなくて
・static領域はゼロクリアされていないことを仮定する
ノカー。

そこまで疑うなら「代入文で値が書き変わる」とか「配列が宣言した大きさど
おり確保される」ことも疑ってかかるに違いない。

まともなプログラム書けんじゃないか。

ホントに基地害だなこの片岡って
しかも、何度叩かれても平然と同じこと繰り返す粘着ぶり
こわー

>> exit前のfreeは書かなければならないものなのか、
>> それとも書かなくても良いものなのか
>>
>> という疑問に、どうやって解答すれば良いのですか？
>こう答えればよいでしょう。
>
>なぜ exit が出てくるのか？
>あなたは、互いに関係のない話を分離する訓練をするべきだ。
>具体例を１つ、安直に exit するな。
だれかこの基地害をなんとかしてクレー。

箱氏はどうなんだろう。
こいつもほとぼりさめたらまた出てくるんか。

>> 2. 制約ができるはずなのにレイヤー間の結合が疎になるという謎の主張.
> 制約と結合って関係ないと思います。

こんな酷い無知を晒して議論続行なんて普通は出来んよな。
結合の意味知らずに疎になるも密になるもねーだろうに。

>>656
箱氏は週に一度おこる発作だと思うけど。

箱の場合、日本語に対して普通の日本人が理解している意味としばしば食い違って
解釈しているのが問題なんだろう。原則とか密と疎の意味とかね。だから議論が
ここまでかみ合わない。

Sugihara は単に経験が足りないだけ。いわゆる素人。だからよく意味もわからず
にこの議論に首を突っ込んでいるのだろうなぁ。

片岡は本物の既知街。上の両者なんか全然問題にならないよ。こいつは放っておい
た方がいい…。特にこれ、

># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか？

やばすぎだろ。断言するが、こいつ絶対まともなプログラムを組めない。

あげ荒らし逝ってよし

片岡(<[email protected]>)
>そう、議論する場です。
>[email protected] で、あなたがしたことは
>ハッタリかまして人を愚弄することだけであり、
>何ら「議論」にあたる内容が含まれていませんでした。

Kumano Akio(<[email protected]>)
>> そんなはずはない、ことが起きているのがアサーション・エラーです。
>
>この一文に限っては同意できます。
は議論に関係ないらしい。
ちゅうか、片岡自分の発言に酔ってるだろ。
誰か片岡にここ見せてやれ……いや、基地外に見せても無駄か（藁

片岡ってどこで働いているんだろ。仕事で奴と関わりたくないから
情報きぼん。

箱発症

>>662
かなり重症の模様。

〜〜
> というか、main側の処理状況って確認できるんですか?

きれい汚いは別として、やればできますよ。
例えばグローバル変数でフラグを立てるとか．．．
〜〜

かたおかきゅん、スゴイ！スゴイヨ！
main との結合が弱くなるプログラムと言っておいて
グローバル変数を参照するのカ〜。

>>664
片岡はもっとすごいことを言っている。

> 「不要」かどうか判定するためには、
> プロセスが解体中または解体されようとしていることを
> 検出できることが必要です。
>
> つまり、free しようとしているモジュールから
> main 側の処理状況を確認する必要があるのです。

プロセスが解体中であることをそのプロセスで実行されている
プログラムで検出するには、プログラムが実行中にもかかわら
ずプロセスが解体されてしまう環境でなければならない。

ふつうの人なら、プロセスを解体する前にそのプロセスで実行
中のプログラムを停止させると考えるんだが、片岡はそう考え
ない。

ふつうじゃないから。

片岡(<[email protected]>):
> > 終了前のfreeを省くと問題（メモリリーク等）が起こるのか、
> > それとも、省いても問題は起こらないのか
> >
> > という疑問に、どうやって解答すれば良いのですか？
>
>exit を終了と言い換えただけ。答えは同じです。
ってことは……

なぜ 終了 が出てくるのか？
あなたは、互いに関係のない話を分離する訓練をするべきだ。
具体例を１つ、安直に 終了 するな。

って答えろってこと？ わけわからん。

>>666
うわ〜。全然答えになっていないですね。片岡は正真正銘の既知だな。

お互い、相手の言い回しに反射的に答えてるだけじゃ収束しようがないね。
free派はそういう泥沼化を目指すしかないんだろうが…

片岡:
>>>なぜ exit が出てくるのか？
>>>あなたは、互いに関係のない話を分離する訓練をするべきだ。
>>>具体例を１つ、安直に exit するな。
>> この記事、わけわかんないです。
>ここまではいいですが、

片岡、自分が既知害だということを認める。（藁

malloc したら必ず free しなければならない。一切の例外は認めない。

終了したスレに煽りはやめれ

この嵐の後すっかり寂しくなっちゃったね。> fj.comp.lang.c

誰か fj.comp.lang.c にまた爆弾を投げ込んでくれ。最近 fj.comp.lang.c
だけじゃなく、fj.comp.lang 自体がつまらない。

>>670
なんであげるんだよ。

>>674
上げ荒らしだから。（ｗ

comp.japan (w

亀と同じく箱も人工無能であるという説に一票。

期待に応えて箱登場！マジかよ（ｗ

おまけに亀同様の時間差攻撃を身につけている様だぞ。

＿こうやって
先頭の空白にアンダーバーをつけるのがコツなんだよ>>箱さま

これでとどめをさしたね。

＃返信への返信には約９０日かかるだろう。

>>670

あるマンガ雑誌の今週号にこんなのがあった。

花壇の花には毎日水をやらなければならない。
雨がどれほど降っていようと関係ない。
例外は一切認めない。

>>680 >>682
ﾜﾗﾀ

>>683
なんというか…。教条的ですなぁ。花に水をやりすぎると枯れるんだよ。

雨がたくさん降っているときに花に水をやることに価値はないだろ
うという話をしているのに、私は毎日かかさず水をやるだけだ、雨
が降っているかいないかは関係ないと言いだすのが箱氏。
自分一人で勝手にやっているだけならいいようなもんだけど、他の
人も原則としてそうするべきだと言いだすのが箱氏。

箱より片岡をどうにかしてくれ。

まだどこかで暴れてますか？＜片岡氏

今のところは沈黙しているようです。 < 片岡

良スレにつき、定期sage

ネタ枯れにつき（まあ当然だが）スレ読み返す。
フォロー忘れてたんで書いときますわ。

>>545 なんだけど、

？：malloc-free がない環境では
？：例えば組み込み環境など
Kono氏：むしろそういった環境でこそ防壁が必要

という流れがあったのを批判的な読みとして
「それこそ malloc-free を使えばいいじゃんか」などと
言い出す人(>>571)はやっぱり元記事読んでないんでは？

私も fj.sci.physics あたりの Kono 氏投稿を読んでるから
責めたくなる気持ちはわかるが、批判なら元の文脈から外れた
字面だけで責めるのはアウト。

ageとくか

ageんなよ！

そうだよ、ageんなよ！

憂慮薄れだ上げるぞ