5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名無しさん@1周年:2001/02/02(金) 03:25
徐々に成長しています。
http://news.dinf.ne.jp/news/fj/comp/lang/c/thrd10.html


2 :名無しさん@1周年:2001/02/02(金) 03:27
よく飽きないなぁと関心しております。>>Junn Ohta

3 :名無しさん@1周年:2001/02/02(金) 06:26
おれはデストラクタお任せ派なのでカヤの外(藁

4 :名無しさん@1周年:2001/02/02(金) 06:51
¡¡¤³¤Î²ñÏá¢\꡼\¯¤·¤Æ¤Ş¤»¤ó¡©

¡¡¤Ç¤Ï¡¢


5 :名無しさん@1周年:2001/02/02(金) 07:21
>>4
ヌ、ナキニイーハウー


6 :名無しさん@1周年:2001/02/02(金) 08:47
>1
まるで台風情報みたいだなよ

7 :名無しさん@1周年:2001/02/02(金) 09:05
!!?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

8 :名無しさん@1周年:2001/02/02(金) 09:06
!!?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



9 :名無しさん@1周年:2001/02/02(金) 09:51
半年ぐらい前もやってたよな。
しかも、同じような質問で

10 :名無しさん@1周年:2001/02/02(金) 09:56
>>3 これで君も仲間だ
newで生成したオブジェクトは、deleteで破棄する
と思いますが、このdeleteを行わないで、そのプログラ
ムを終了させたら、生成したオブジェクトは残ってしまう
のでしょうか?

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

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

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


11 :名無しさん@1周年:2001/02/02(金) 10:00
おれはJavaでGCお任せ派なのでカヤの外(藁


12 :>10:2001/02/02(金) 10:05
deleteは無条件でやらないとだめだろ。
メモリの開放だけじゃないんだから。

13 :名無しさん@1周年:2001/02/02(金) 13:01
おれはC/C++でスタティックなのでカヤの外。(藁

14 :名無しさん@1周年:2001/02/02(金) 13:21
>>10
UNIXだとmalloc()が中でbrk()やsbrk()使ってOSからメモリを
貰ってやってるのが普通だと思うな。で、終わったらプロセスに
関連するメモリを開放する(他プロセスと共有している部分は残す)。

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

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

15 :名無しさん@1周年:2001/02/02(金) 13:29
C++でnewしたやつをdeleteしないのは危険だろ。
デストラクタ呼ばれなくなるし。

16 :名無しさん@1周年:2001/02/02(金) 13:52
こんなんあったけど(藁
http://www.hajimeteno.ne.jp/cgi-bin/tree_bbs/bbs.cgi?num=4029&ope=sel&id=

17 :名無しさん@1周年:2001/02/02(金) 14:00
こっちのMLは朋子嬢のMLと比べて厳しいレスがポンポン帰ってくるなぁ〜
見ていて気持ちがいいね!
この人達が朋子嬢の相手してくれればいいのになぁ・・・

18 :名無しさん@1周年:2001/02/02(金) 14:35
あの ML は朋子の ML じゃねーよ(藁

19 :名無しさん@1周年:2001/02/02(金) 14:35
>>17
ネタかも知れないけれど、MLじゃないよ。

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

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

だから何? >>20


22 :20:2001/02/02(金) 16:29
>>21 「だから何? >>20

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

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

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

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

23 :名無しさん@1周年:2001/02/02(金) 16:40
烏有さんを発見

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

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

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

25 :名無しさん@1周年:2001/02/02(金) 18:14
>ANSI規格的にはfreeは必ずしなくても良いが・・

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

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


26 :名無しさん@1周年:2001/02/02(金) 18:24
う〜ん、自分はDOS時代から先輩には「malloc()とfree()は対で使うべし」と
教え込まされたなあ。
プログラム(プロセス)が終われば解放されるといっても、うちの作るソフトは
たいてい365日24時間ずっと動きっぱなしの監視システムだからだったと
思うけど。

27 :名無しさん@1周年:2001/02/02(金) 21:07
今、1で紹介されてる議論よんできたよ。
なかなか面白いね。
メモリリークと
malloc & free
は直接関係ないんだね。

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

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

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

29 :名無しさん@1周年:2001/02/02(金) 22:00
ログあんまりまじめに読んでないけど、
free()は呼ばなくていいし実際呼んでない。って奴はいないんだろ?
ほんと2ch以上にくだんない議論をよく飽きずにやってるよ。

30 :ななし:2001/02/02(金) 22:22
え〜 long durationなプログラムでは、初期化以外でmalloc族は使わないように根性で書くけどな……

31 :名無しさん@1周年:2001/02/02(金) 22:57
>>30
途中でメモリを確保しないってこと? そりゃすごいねぇ

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

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

34 :名無しさん@1周年:2001/02/02(金) 23:16
んーと、
むつかしいことはよくわからんけど、
freeの動作はmallocが再度利用できるように
mallocが利用していた領域を解放するんで
必ずしも=「OSに領域を返す」て意味ではないのである、
そういう意味では必ずしもメモリリークを防ぐための手段とは
なり得ないのであるるる、
なかには、結果的にそうなる実装のコンパイラとOSもあるかもね、
ということでよいか?

35 :>34:2001/02/02(金) 23:21
了解しました。
つまりちゃんとしたOS・コンパイラであれば
for(;;)
p = malloc(1);

for(;;){
 p = malloc(1);
 free(p);
}
は意味的に同じで、どちらもメモリリークしないということですね。
なっとく。

36 :名無しさん@1周年:2001/02/02(金) 23:28
>34
上のやつはだめだよう。
ヒープがたりなくなるよう。
まぁ、それをリークとは言わないよね
実際確保している領域だから。

37 :名無しさん@1周年:2001/02/02(金) 23:35
ごめん、>34じゃなくて>35ね、アハハ、、

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

39 :名無しさん@1周年:2001/02/02(金) 23:44
そいや jdk1.1 系の JVM って、
ガベコレしたメモリをシステムに返さないで抱え込んどくよね。
けっこう迷惑。
すれ違いで迷惑sage

40 :名無しさん@1周年:2001/02/02(金) 23:51
>そいや jdk1.1 系の JVM って、

jdk1。3とかは問題ないのかしら。

41 :名無しさん@1周年:2001/02/03(土) 00:00
ていうか、

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

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

42 :名無しさん@1周年:2001/02/03(土) 00:06
Delphiは大きな領域をGetMem, FreeMemすると
ちゃんとその場でOSに返すよ。

43 :名無しさん@1周年:2001/02/03(土) 00:14
>40
NTでは大丈夫だったよん。ついでにThreadに無駄にでかい領域
割り当てないようになったみたいなので、今死ぬほどThread
上げまくって遊んでみてます。

44 :名無しさん@1周年:2001/02/03(土) 00:19
つーか、リークの定義って何?
なんか交錯しててよく分からん。
私の定義は、「確信犯以外の解放し忘れは全部リーク」
メモリだけじゃないよ。

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

45 : :2001/02/03(土) 00:31
>>44
上位アプリケーションレベルでは普通やらないよね。
JVMとかデバッガとかVMWARE?とかシステムに近いところ、
「環境」みたいなもの、クリティカルなものは当然使い分けるべき
だけどね。


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

47 :名無しさん@1周年:2001/02/03(土) 01:05
>>46
GetMem,FreeMem はC言語で言うmalloc/freeと同じだよ。
Delphi のメモリ管理関数は GetMem/FreeMem が基本。

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

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

48 :46 > 47:2001/02/03(土) 01:27
ごめんね。ろくに調べずに否定しました。

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

49 : :2001/02/03(土) 01:37
ところで VirtualFreeってシステムコールなの?
ただのapiライブラリなの?
システムコールなら、どんな挙動するものなの?
apiなら、中は free みたいなものではないの? 違うのかな?

50 :名無しさん@1周年:2001/02/03(土) 03:04
>>48
そのかわり安定性が犠牲になります。


51 :名無しさん@1周年:2001/02/03(土) 03:30
>>48
ページが解放されれば速攻つかえるだろ。


52 :名無しさん@1周年 :2001/02/03(土) 04:25
ニュースグループの人たちはキディガイですか?
一般社会でまともに生活できなそうですね。

53 :>51 マジ?:2001/02/03(土) 04:31
いやな、

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); とかが
もらえる、なんてこと、あるの? 信じられんな。 どんな管理してるんだ?

54 :名無しさん@1周年:2001/02/03(土) 05:13
>>53
断片化の話ですか?

55 :名無しさん@1周年:2001/02/03(土) 05:25
>>42 「大きな領域をGetMem, FreeMemすると ちゃんとその場でOSに返す」
>>47 「FreeMem 関数内でVirtualFreeを呼ぶ…領域をOSにすぐに返す」

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

56 :名無しさん@1周年:2001/02/03(土) 05:29
malloc/free論争って要するに規格を拡大解釈することを良しとするかしないかを争ってるんですよね?

57 :51:2001/02/03(土) 06:31
>53

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

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

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


58 :名無しさん@1周年:2001/02/03(土) 07:23
Win32だったら、Heap系のAPI使った方が楽は楽。
使いたいときにヒープオブジェクト作って、そこからちまちまアロケート。
要らなくなったらヒープオブジェクトを解放すれば、すぐにOSにメモリが
返せる。
HeapCompactなんてAPIもあるしな〜。可能ならdecommitするよ。

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

59 :名無しさん@1周年:2001/02/03(土) 07:24
>>53
一般のアプリではページごとに局所化されるように意識して描かない
ですよね。それともDelphiでは4Kを意識してヒープ使うわけ?普通。

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

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

60 :名無しさん@1周年:2001/02/03(土) 07:33
メモリリークの定義は
どこからも論理的に正則には参照できない領域が
残ってしまうこと
をいうのではないかい?

>>35

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

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

61 :名無しさん@1周年:2001/02/03(土) 09:16
Delphi はC言語ではない、つまりANSI C規格とは全く無関係だから
そこをふまえておいてな。

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

62 :名無しさん@1周年:2001/02/03(土) 10:12
本気でソースを読むつもりはないから無責任なんだけど、
GetMem.incをちらっと眺めると、
InsertFree,MergeCommit,WalkHeap,AddBlockAfter,...
みたいに、自前で管理しているとしか思えない処理があるんだけど。
見るところ間違ってる?

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

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

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

63 :ねかま:2001/02/03(土) 10:16
>>60

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

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

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

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

64 :ボログラマー:2001/02/03(土) 12:15
「VCだと開放して無いメモリ」の事を「リーク」と称している感じ。


65 :名無しさん@1周年:2001/02/03(土) 12:52
>>61
ということは、Delphiではアプリケーションプログラマが
4バイトほしいときも200Kバイト欲しいときもGetMemしてるってこと?
そして(普通は)deleteとかfreeと同じ感覚でFreeMemしてるってこと?

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

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

66 :名無しさん@1周年:2001/02/03(土) 12:53
>>64
メモリ確保したとたんリーク呼ばわりなの? うそーん

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


68 :名無しさん@1周年:2001/02/03(土) 13:48
>>66
確保してそのまま使われずにほっておかれるってことじゃないの?

69 :名無しさん@1周年:2001/02/03(土) 13:49
>>47より
>ソースコードを見てみたが、FreeMem 関数内でVirtualFreeを呼ぶコードが
>あるので領域をOSにすぐに返すことはやっているようです。

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

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

まったくだよ。

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

71 :名無しさん@1周年:2001/02/03(土) 14:07
>メモリ確保したとたんリーク呼ばわりなの? うそーん

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


72 :66:2001/02/03(土) 14:21
>>71
なるほどそう読めますね。なっとくしました。

73 :名無しさん@1周年:2001/02/03(土) 14:22
67の引用元はどこだろう?
46さんの最初の2行は67の後半と同じ事を言っていると思うんだけど、
それを否定してる41&47&61さんの反論待ちですね。

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

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

76 :ねかま:2001/02/03(土) 17:17
終了時にfreeしてようとしてまいと、
解放するしないはOSの責任だずら。
それ、mallocの話じゃなくなってるジャーン。

77 :名無しさん@1周年:2001/02/03(土) 17:33
>解放するしないはOSの責任だずら。
あれ、この手の議論は
「終了までの間に必ずfreeすべきだ」対
「終了時にOSが解放するから、freeは必要ない」でしょ?

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

78 :77:2001/02/03(土) 17:45
ごめん、リークの話題だってことに気がつかなかった。

79 :ねかま:2001/02/03(土) 18:52
それてるなんていってないジャーン。

だが、本質ではないよ。

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

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

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

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

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

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

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

というのではダメかね。


80 :名無しさん@1周年:2001/02/03(土) 19:47
>>79
追加
「exit()直前のfree()は不要である」
これは正しい?

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

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

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

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

83 :ねかま:2001/02/03(土) 20:50
そんなコメントいれるなら素直にfreeしたほうがはやいわね、ホホホ


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

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

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

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

85 :ねかま:2001/02/03(土) 20:51
あら、すれちがい、ちょっとおまち。今よむわよ。

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

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

87 :ねかま:2001/02/03(土) 21:38
あおるつもりはないのだけど、
おっしゃってることがよくわからないわ・・
ていうか、アタシの話を論証しているようにしかみえないわ。

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

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

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

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

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

88 :ねかま:2001/02/03(土) 21:39
長々と書いてしかもサゲちゃったじゃないの、、、、

89 :ねかま:2001/02/03(土) 21:58
アタシの書いた文章、論理がおかしいわ、、、
まぁ、広い心でよんでちょうだい。
いいたいことは変わらないわ。

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

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


90 :ボログラマー:2001/02/03(土) 22:09
今時の環境で(通常の)メモリが1〜2Mリークして、
OSが握ったまま放さなくても、正直困らないわけよ。
そのうちスワップアウトするだろうから。<しないと困るな・・・

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

91 :47:2001/02/03(土) 22:30
俺が言いたかったのは領域をOSに返却する処理がアプリ終了時以外に
FreeMem関数内でも行われることです。

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

92 :名無しさん@1周年:2001/02/03(土) 22:33
free(malloc(0));

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



94 :46:2001/02/04(日) 00:09
えー!!
   >>42 「Delphiは大きな領域をGetMem, FreeMemすると
       ちゃんとその場でOSに返す」

   >>91 「領域をOSに返却する処理がアプリ終了時以外に
       FreeMem関数内でも行われることです」

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

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

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

氏のう。鬱のせいで。
   ∧||∧  ∧||∧  ∧||∧  ∧||∧  ∧||∧
  ( / ⌒ヽ ( / ⌒ヽ ( / ⌒ヽ ( / ⌒ヽ ( / ⌒ヽ
   | |   |  | |   |  | |   |  | |   |  | |   |
   ∪ / ノ  ∪ / ノ  ∪ / ノ   ∪ / ノ  ∪ / ノ
    | ||    | ||   | ||    | ||   | ||
    ∪∪   ∪∪   ∪∪    ∪∪  ∪∪

95 :名無しさん@1周年:2001/02/04(日) 00:30
47は46の内容を理解していたのだろうか。
>領域をOSにすぐに返すことはやっているようです。
>ろくに調べずに否定するのはどうかと思うが。
と言った後で
>誤解を招いてしまった。
間違えたわけではないのか。
往生際もすばらしい。

96 :名無しさん@1周年:2001/02/04(日) 00:58
つーかWindowsよくしらんけど、プロセス終わってリソース解放しない
OSなんてあんのか? なんのためのOSだ?
そういうことはしっかりやれよ > OS
共産党の作ったOSなーんだ? OSAKA

97 :名無しさん@1周年:2001/02/04(日) 02:03
>>96
やばいよ〜そういうネタは。
タテジマの宣伝カーがやってくるよ(w

98 :名無しさん@1周年:2001/02/04(日) 08:04
右翼age

99 :名無しさん@1周年:2001/02/04(日) 12:54
>>96
あちきの理解では、WindowsNT とか2000はUNIXなみにできてると
思うんだけど。。。違うのかニャ〜

100 :名無しさん@1周年:2001/02/04(日) 13:15
>99
つーか、UNIX(のコンパイラ)はプロセス終了しないと
取得したメモリを開放できないんでしょ?
Windows NT/2000どころか95以下じゃん(プ

101 :名無しさん@そうだ選挙にいこう:2001/02/04(日) 13:26
自分で開けたものは、自分で責任持って閉める。
自分で借りたものは、自分で責任持って返す。
プログラミングにおいても、一般常識と同じ。
他力本願は駄目。

102 :ねかま(ねおき):2001/02/04(日) 13:31
選挙にいこう、じゃないわよ、
自分で開けたものが閉めても閉めなくても
閉まらない場合があるって話してるのよ。
閉めて閉まるならこんな話誰もしないわよ。
もう何いってるかわからないわ。

103 :名無しさん@1周年:2001/02/04(日) 13:33
アレ、ちゃうちゃうちゃう?

104 :名無しさん@そうだ選挙にいこう:2001/02/04(日) 13:46
>自分で開けたものが閉めても閉めなくても
>閉まらない場合があるって話してるのよ。

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

105 :ねかま:2001/02/04(日) 13:53
あなたいいこというわね。
でもメーカーは知らん顔だし、アタシには直せないわよ。

106 :名無しさん@1周年:2001/02/04(日) 14:37
>>99
あー、それはアンタがなにも知らないから。
stdのCライブラリの実装にはそういうのが多いけど
そうじゃないのもあるよ。OSの問題ではないんだ。

107 :名無しさん@1周年:2001/02/04(日) 14:48
>>106
もの知りのあんたに質問だ。
UNIX系のOSで「そうじゃないの」の例を挙げてみてくれ。
その「そうじゃないの」はどうい実装になってるか説明してくて。

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

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

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

109 :名無しさん@1周年:2001/02/04(日) 15:37
>>108
メモリデタッチとかエスティメイトとか一般的でないカタカナ英語
使うのやめてくれんかのう。日本語にある言葉を使ってくれ。


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

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

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

111 :名無しさん@1周年:2001/02/04(日) 16:26
>>108 >>110

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

112 :名無しさん@1周年:2001/02/04(日) 16:38
なるべく日本語になおしただけだろう?
>>109なんか無視すればいいだろヴァカ

113 :ねかま:2001/02/04(日) 16:42
もちろんキチガイよ。
こむずかしいこと並べられても読む気もしないわよ。


114 :名無しさん@1周年:2001/02/04(日) 16:46
>>110
この書きなおしで分かりやすくしたつもりなんかな?
人に説明するのは苦手なタイプなんだろな。きっと。

115 :名無しさん@1周年:2001/02/04(日) 16:51
>>113-114
わからないから説明してとたのまれてそこそこ詳しく説明したら
難しいだのわかりにくいだの言う。
「分数できなくても人生に影響ない、先公にオレらのなにがわかるんだ!」
といって算数を勉強しない厨房といっしょなので、以後プログラミングは
禁止します。 (ププ

116 :名無しさん@1周年:2001/02/04(日) 16:52
>>113
別にこむずかしくないぞ。

117 :116:2001/02/04(日) 16:53
>>115 かぶったスマリ

118 :ねかま:2001/02/04(日) 16:56
皮肉よ。

119 :名無しさん@1周年:2001/02/04(日) 17:01
うざいな他でやれよ。逝ってヨC

120 :名無しさん@1周年:2001/02/04(日) 17:03
相手がエンジニアだと思って説明してくれたんだろう
ただの厨房だとわかってゲンナリしてるだろうな・・・
ROMしてるヤツらもいるから気にすんな >110

121 :名無しさん@1周年:2001/02/04(日) 17:04
>>115
本当に理解してる人間はもっと要領よく整合性のある説明ができます。

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

122 :名無しさん@1周年:2001/02/04(日) 17:07
じゃオマエやれ >>121

123 :名無しさん@1周年:2001/02/04(日) 17:10
>>122
内容のない煽りはsageでやってください。

124 :106:2001/02/04(日) 17:11
>>121 珍しく頭にキタ!
なんでそんなヒマなことしなきゃいけないんだ?
UNIXでどうなの?と聞かれたから、知っている範囲で書き込んだだけ。
気に入らないんならよそで勉強するか、間違いを指摘するかしろよ。
どこだよ? え? どこが間違ってて、どこがWEBの資料なんだよ?
言えよこら。

125 :106はあってるじゃんかよ:2001/02/04(日) 17:12
なんで荒れるかね。このスレが。。。
アラシは他でやってチョ >> 121

126 :名無しさん@1周年:2001/02/04(日) 17:14
>124 ほっとけよヴァカ
コピペだとしか煽れない事自体、他がわかってないってすぐわかるだろうに…

127 :名無しさん@1周年:2001/02/04(日) 17:16
>>124
だから、sageでやってくれよ(;´Д`)

128 :106:2001/02/04(日) 17:16
>>126
だってひどいじゃないかよー! ムカつかない?
なぜわからないことまで煽ろうとするかなあ。。
もうやめた。どうせこいつらUNIXなんて一生縁がないんだろ。ムダムダ。ふん

129 :>128:2001/02/04(日) 17:20
かちゅ〜しゃで簡易あぼ〜んすれば気にならなくなるよ。
どの番号のレスをあぼーんすればいいかのリストを作ってあげるから
それで見てみて!
誰が見ても >>121 は単なる荒しじゃん。あんた2chに慣れてないんだろ?
ここは確かに少ないほうだけど、やっぱりいるから。こういうの。健全な証拠だ。
気にするな。

130 :ねかま:2001/02/04(日) 17:21
106の文章が反感買っただけよ。
皮肉を言っても通じなくて、あげく解答も切れが悪くてイヤミだったのよ。
内容が正しいかどうかってことじゃないわよ。

131 :名無しさん@1周年:2001/02/04(日) 17:22
       ∧ ∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′ ̄ ̄( ´∀`)<  あーあ、怒っちゃった。マターリ逝こうよ
 UU ̄ ̄ U U   \_____________

132 :名無しさん@1周年:2001/02/04(日) 17:27
おいねかまよ、男らしいところみせろや(藁
100みたいな間違い放置するよりましだろうが。
121も謝っとけよ・・・ ったく

133 :121:2001/02/04(日) 17:31
ごめん。あまりに食いつきがよさそうなので、つい煽ってしまいました。

134 :ねかま:2001/02/04(日) 17:31
なんでアタシに振るのよ(W

135 :名無しさん@1周年:2001/02/04(日) 17:33
121も謝ったし、マターリ進行でいきましょうか。

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

137 :元PG:2001/02/04(日) 17:39
ところで121さんは他の実装をご存知なのですか?
なんかそう読めたんですが・・・
教えてください。私には>>108の説明は一般の理解のレベルではなく
疑問に思った人の理解を充分補うものだと感じるんですが。
あ、私にはわかりやすく説明していただかなくて結構です。
詳しいほうが嬉しいです。

138 :名無しさん@1周年:2001/02/04(日) 17:49
なんだなんだおまえら・・・ ちょっとまてよ。
このスレたどると、
アプリ − サポートライブラリ − システムコール − 仮想記憶空間
の関係性がわかってないやつがいるな。
なんにせよスマートXXでもなんでもいいけど、やった女は池に戻せ、だ。

139 :名無しさん@1周年:2001/02/04(日) 17:51
しょせんWindowsのアーキテクチャはVAXのパクリでしょ。
そんなには変わらないよ。UNIXだって。

140 :名無しさん@1周年:2001/02/04(日) 19:27
>やった女は池に戻せ

御意。

141 :名無しさん@1周年:2001/02/04(日) 19:46
121、ねかま反省中
厨房さらしsage

142 :ねかま:2001/02/04(日) 21:38
なんでアタシが反省中なのよ。
美容院行ってたのよ(ほんとは床屋な)

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

143 :名無しさん@1周年:2001/02/05(月) 02:14
この板のレベル、さらしとこう

144 :名無しさん@1周年:2001/02/05(月) 12:45
おいおい もうおわりかよ
なんかないのか? 具体的な内容なんて1つか2つくらいしか
でてないじゃんかー
頼むぜ自称プログラマしょくん (和羅

145 :名無しさん@1周年:2001/02/05(月) 12:51
> もちろんキチガイよ。
> こむずかしいこと並べられても読む気もしないわよ。

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

ねかま、氏ね


146 :名無しさん@1周年:2001/02/05(月) 12:59
>>144
自分が理解できる事=具体的な内容と勘違いしているのは痛いです。
理解できないのに下らん煽りをするのはウザイです。
お願いですから消えて下さい。

147 :144:2001/02/05(月) 13:24
>>146
そうか?
何番のレスが意味があるのか言ってみろ

148 :名無しさん@1周年:2001/02/05(月) 14:45
>>146
なんだかんだ言って具体的な話には絶対入ろうとしないな。

149 :144:2001/02/05(月) 15:37
>>148
ソーダソーダ!
ちょっとは具体的なこといってみろってんだ
つーの

150 :146:2001/02/05(月) 17:08
>>147-149
>何番のレスが意味があるのか

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

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


151 :名無しさん@1周年:2001/02/05(月) 20:53
身のある話がもっとききたいゾナsage

152 :( ´∀`)さん:2001/02/05(月) 21:03
          || ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄||
          || 煽りに    .   .∧_∧  カッコワルーイ!
          ||  マジレス..!\ ( ゚Д゚.)
          ||_______⊂⊂  |

  ∧ ∧    ∧ ∧    ∧ ∧  | ̄ ̄ ̄ ̄|
  (  ∧ ∧ (   ∧ ∧ (  ∧ ∧        |
〜(_(  ∧ ∧ __(  ∧ ∧__(   ∧ ∧ ̄ ̄ ̄
  〜(_(  ∧ ∧_(  ∧ ∧_(   ∧ ∧  カッコワルーイ!
    〜(_(   ,,)〜(_(   ,,)〜(_(   ,,)
      〜(___ノ  〜(___ノ   〜(___ノ

153 :( ´∀`)さん:2001/02/05(月) 21:13
>>150
そういうことじゃないんじゃないかな。煽られてるのは。
読んでみたけど、ウソや間違いや厨房の意見が多くて
なるほどと思える書き込みが少ないってことだよ。
まああんまりにも厨房ばかりでマジで書いた人も呆れた
ってとこじゃない?オレも読んだけど2,3わかってる人が
書いたのがあるけど、理解力の無いヤツが難しいだのムカツク
だの書いてる(藁
平均するとこの板のレベルなんてこんなもの。まあ2chなんて
だいたいそうだ。高校生しかいなくなったクラブみたいなもんだ。
つまんなすぎ

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


155 :144だけど:2001/02/05(月) 22:30
>>150
144=20=108なんだけど、気持ちわかってくれる?
他にあまり具体的なものを読み取れなかったんだよ。
自分はかなり具体的に書いたつもりだったので。
紛らわしくてすまんかったが。

156 :sage忘れた (; ゚Д゚) マジスマン:2001/02/05(月) 22:30


157 :名無しさん@1周年:2001/02/06(火) 06:24
敢えて言うけどさ、>>108等を読むと、
>>20
>メモリ確保の用途に予測可能な規則性がある場合はそれ用の実装をすることは
>ありますが、あくまで汎用のnew/delete の場合は上記のようにOSから取るばかりで
>返還しません。
が「ライブラリの仕様」であって、「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及びそれ以降のページ境界議論の中で
暗に示そうとしているようにも思えるが、それは違うか。

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

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


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

159 :157=158:2001/02/06(火) 06:49
まだ誰にも読まれてないうちに。
158の最後は「自分は底辺じゃないぞ」のつもりで書いたわけじゃないからね。

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

160 :名無しさん@1周年:2001/02/06(火) 08:29
2chなんだから、チュウボウがなにかと上下関係をつけたがるのも
気に障るほどのことでもないけど、まあ技術系の板なんだから
多少は技術的な情報としての価値を重んじる方向性でやってけば
いいんじゃないの。レベル低いのは別にかまわないけど、
あまりに無用な煽りなんかは、なんていうのかな、もったいない
って感じるけどね。

161 :名無しさん@1周年:2001/02/06(火) 12:04
なーんか、108が20だとすると、ほんとにわかってるの?って
疑問を持つ部分が無くもないような。

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

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

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

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

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

163 :名無しさん@1周年:2001/02/06(火) 14:06
「OSによって差がある」=「OSのシステムコールに差がある」ではなくて、
「OSによって標準ライブラリの実装が違う」から、「差がある」でしょ?
それは「OSによる差」ではなく、「ライブラリによる差」と言うんでは無いの?

164 :名無しさん@1周年:2001/02/06(火) 14:33
OSによって違うってのは、例えば
BSD系は縮小方向へのbrkが成功するけどSysV系は失敗する
等の場合だと思うんだけどね。
WindowsならVirtualAllocの動作とか。

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

165 :164:2001/02/06(火) 14:37
ごめん、質問に答えてないや。
コンパイラの件について、「どうなのかね?」とは、
単に、「コンパイラとは関係無い」に対して、
リンカまで含めた広義の「コンパイラ」なら関係あるんじゃないか?ってこと。

166 :20:2001/02/06(火) 16:51
>>165
マジレス

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

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

167 :sage忘れた (; ゚Д゚) :2001/02/06(火) 16:52
ほんとゴメン

168 :162:2001/02/06(火) 17:01
ああ ごめん >>161 はそういう意味だったのね。
malloc/free の振る舞いは直接OSの差によるものではないね。
それでもOSのメモリ管理の挙動に差はあるけど。

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

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

では。

169 :名無しさん@1周年:2001/02/06(火) 17:36
>「煽りでしたすみません」となってたみたいだけど。
本気にするなよ。それは偽物なんだから。

170 :名無しさん@1周年:2001/02/06(火) 18:31
どーでもいいや

171 :164:2001/02/06(火) 18:59
疑問なんだけど、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の仕様である。
これが望んだ「具体的な内容」が出ない理由でもある。
※もし、煽りの理由が他にあったらすまんね。

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

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

172 :ヲイヲイ:2001/02/06(火) 19:54
>>171 横レスでスマリだが、ちょっと忠告。
170でどうでもいいと書いてしまったが 171を読んで気になったことがあった。
171が問題にしている事は単なる揚げ足とり。問題はmalloc / free の挙動
について知っておくべきことのはず。揚げ足とりもいいけど大事なのは実際に
ナニが起こって、どうなるかということ。それについて具体的に解説されて
いることが大事であり20以下が唯一の説明だ。

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

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

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

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

173 :ヲイヲイ:2001/02/06(火) 19:56
>>171
× >>107

174 :名無しさん@1周年:2001/02/06(火) 20:08
>>172
うっさいなあ・・・
アンタがわかってるってことはよくわかったから sageろよ ヴァカ

175 :164=171:2001/02/06(火) 20:55
ごめんよ。用語の使い方は俺の方を訂正する。<コンパイル
元々、108で出た言葉が100への返答だと気がつかなかったから。

俺の番号に一貫性がないのがいけないんだけど、
>>171 「何訳わかんねー事聞いてんだコイツ」というのが普通の反応
>とは到底思えない。文面からはっきりわかるのは 20の説明がわかっていたのは
>>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を書いたのかも。

176 :164=171:2001/02/06(火) 21:28
ま、157を書き始めた理由が煽りにむかついただから、あら探しもするさ。
でも、また誤解されそうなところを訂正ね。

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

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

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

177 :164=171:2001/02/06(火) 21:32
>私や157のように20の解説がわかるものにとっては、>>171 の書いてることは単に
>どっかのレスを論破されたことで主旨を捻じ曲げて絡んでいるだけにしか見えない。
論破されたつもりはないが、煽りにむかついてたから
趣旨を捻じ曲げて絡んだのは事実かもね。157=171だけど。

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

178 :ねかま:2001/02/06(火) 22:00
なんでアタシは論外なのよ。
しつれいしちゃうわね。

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

180 :51:2001/02/06(火) 23:11
ま、一通りでたから話すこともないんでしょ。

181 :名無しさん@1周年:2001/02/06(火) 23:18
>>179
解ってないやつの態度次第なんじゃない?
ジョーシキ


182 :(・∀・)(・∀・)(・∀・):2001/02/07(水) 00:08
(・∀・)(・∀・)(・∀・)

183 :名無しさん@1周年:2001/02/08(木) 19:45
>>179
てめーがいなけりゃ、もう少し良い空気だったろーよ。

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

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

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

185 :仕様書無しさん:2001/02/12(月) 05:36
「exit() 直前の free() は不要である。」というのは一致した意見のようだけ
ど、それでも free() をした方が好ましいと考えて、積極的に free() したり、
コメントを書くいる人はいるんですか?

186 :仕様書無しさん:2001/02/28(水) 14:20
まだ収束する気配ないよ...>malloc and free
「電子のお針箱」は前回思いっきりたたかれたのにまた出てくるし
また、数ヶ月続くのかなぁ


187 :仕様書無しさん:2001/02/28(水) 14:25
ひさびさに上がってるね。
>>184
> 「適当に検索エンジンで検索して、文章をつぎはぎして張ったりかます」
> という煽りはまじヤルキ無くすわ。

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

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

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


189 :仕様書無しさん:2001/02/28(水) 15:28
>>188
> Heapが何であるか
(多くの実装で)メモリブロックを取得する場所じゃないかな?

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

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



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


191 :仕様書無しさん:2001/03/01(木) 02:48
>>188
>常にmainで終了するってことが可能
>だと思いますか?

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

192 :仕様書無しさん:2001/03/01(木) 03:19
fj.comp.lang.cって、なんか言い争い多いね。

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


193 :仕様書無しさん:2001/03/01(木) 03:41
もうfj.comp.lang.cは見るのやめて、comp.lang.cに切り替えました。
英語の勉強にもなって良いです。

194 :仕様書無しさん:2001/03/01(木) 10:59
_heapmin()使ってる人いますか?

195 :仕様書無しさん:2001/03/01(木) 11:13
>188
longjmp使えば、楽勝でしょう。

196 :仕様書無しさん:2001/03/01(木) 11:25
割れたチョコレートを
「湯せんするからそのまま返してくれていいよ」
というおなごに、
一所懸命四角に繋ぎ合わせて返す
さえないおとこ。

197 :仕様書無しさん:2001/03/01(木) 13:21
sage

198 :cafe:2001/03/04(日) 05:50
おことがひとりならいいけど、100人もいた。
すぐ割れるチョコをゆせんしまくり。
仕事のトロイ八方美人。

199 :仕様書無しさん:2001/03/04(日) 14:35
漏れの fj.comp.lang.c の malloc/free 総評。

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

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

200 :仕様書無しさん:2001/03/04(日) 15:55
難しいことは、プログラム板の麻衣ちゃんズに聞けば
やさしく教えてもらえるっす。

201 :山師さん:2001/03/05(月) 01:28
haa... C ha rekishi ga nagaikara
damedame yaroumo kokomade kichatterunoka...



202 :仕様書無しさん:2001/03/07(水) 13:15
about this Newsgroup (このニュースグループの使い方)[20010216]
頭のおかしい人の相手をしてはいけません。それは相手の思うツボです。

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

203 :仕様書無しさん:2001/03/09(金) 03:02
この議論さ、ホント見てると頭いたくなるんだ。

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

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

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

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

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


204 :仕様書無しさん:2001/03/09(金) 03:29
>そんな環境依存するもの議論する価値ないだろ。
といいながら、
>素人が誤解産むだけなんだからちゃんとfreeしとけよ。
しっかり、議論を始めてるあたりが、ホント見てると頭いたくなるな。
たぶん脳味噌腐りはじめてる。

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


205 :仕様書無しさん:2001/03/09(金) 09:55
鶴田とかいうヤツ、uzeeeeeeeeeeeeeeeeeeeeee!

206 :仕様書無しさん:2001/03/09(金) 10:00
どちらにしろ、ケースバイケースで考えることを忘れた、
頭の硬い人にはなりたくないです。

207 :仕様書無しさん:2001/03/12(月) 17:14
嫌味、皮肉、あてこすり、見下し。
あーやだやだ。
あれ読むと、リコーとかPFUとかが嫌いになりませんか?(ワラ

208 :仕様書無しさん:2001/03/13(火) 10:02
なんで? 逆では?

209 :仕様書無しさん:2001/03/13(火) 10:07
それよりも>>203のおかげでOh!Xが未だに存在することが
判明しました。インターネットはまったく凄い!

210 :仕様書無しさん:2001/03/13(火) 10:39
> 嫌味、皮肉、あてこすり、見下し。
あそこはコテハンが多い2chなので正常な神経を持つ人が見るものではありません。

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


211 :207:2001/03/13(火) 12:55
>>208
いや、逆ではない。
リコーとかPFUのヤツとかその他の電波なヤツ、ウザすぎ。

212 :仕様書無しさん:2001/03/13(火) 14:32
>「exit 前で freeする必要はあるか?」
>と言う問いに対しては、
>
> ある環境や条件ではfreeが要るかもしれない。しかし、全く要ら
> ない環境や条件も存在する。
>
>従って、
>
>「exit前でfreeが必ず要るというわけではない」
>
>すなわち
>
>「exit前でfreeする必要はない」
>
>と言えるのです。

と言えるわきゃねーだろ(ワラ


213 :仕様書無しさん:2001/03/13(火) 15:03
・ANSI-Cで、
・寿命が短い(GUIでない)、
・C++ではなくCのプログラムで、
・(OSによってはありうる)他の開放しなければならない資源をアロ
ケートしていない

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

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

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

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

214 :仕様書無しさん:2001/03/13(火) 15:08
> いつまでも反論し続けているのかわからん。
変な宗教(mallocしたら絶対にfreeしなきゃいけない教)に入信してるから


215 :仕様書無しさん:2001/03/13(火) 15:22
>>213
>・ANSI-Cで、
>・寿命が短い(GUIでない)、
>・C++ではなくCのプログラムで、
>・(OSによってはありうる)他の開放しなければならない資源をアロ
ケートしていない
という環境が、彼らの世界の全てだから、そこに拘泥しているのでは?


216 :仕様書無しさん:2001/03/13(火) 15:26
デムパっぽいのはお針箱、シロート丸出しなのが Sugihara。

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

news:m31ysaiyct.fsf@maedapc.cc.tsukuba.ac.jp
に対する彼のフォロー
news:984706$sva$1@news.kyosai.or.jp
を読んだかぎりでは相当怪しい。
news:KATE.01Mar7131410@sims211.trad.pfu.co.jp
news:m3wv9y7rr9.fsf@maedapc.cc.tsukuba.ac.jp
で追求されても知らんふりだしな。

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

217 :仕様書無しさん:2001/03/13(火) 15:26
>>215
??
あなた箱さんですか?

218 :仕様書無しさん:2001/03/13(火) 15:40
>>217
> あなた箱さんですか?
漏れもそうオモタ(藁

219 :仕様書無しさん:2001/03/13(火) 16:08
> デムパっぽいのはお針箱、シロート丸出しなのが Sugihara。
に対して、
> 嫌味、皮肉、あてこすり、見下し。
を駆使する面々。

俺は後者のほうが嫌い。

220 :仕様書無しさん:2001/03/13(火) 16:20
好き嫌いで論理の破綻が逆転するわけじゃない

221 :仕様書無しさん:2001/03/14(水) 14:54
ANSI-C においても exit() 直前の free() をした方が好ましいと考える人はい
るのですか?

222 :仕様書無しさん:2001/04/10(火) 17:17
てっきり、自説の恥ずかしさに気がついて、
サイバー自殺したと思っていたのに…

223 :仕様書無しさん:2001/05/01(火) 16:57
1ヶ月ぶりに見てみた。

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

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

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

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

こんなこと言ってるし(´д`)

224 :仕様書無しさん:2001/05/02(水) 02:46
>>203
うーん。その論旨はまさに電子氏にクリソツに思えるのだが?
素人の誤解を数に入れはじめたら電子氏と一緒にドツボにハマルだけ。

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

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



226 :仕様書無しさん:2001/05/05(土) 07:34
とりあえず /usr/proc/bin/pmap -xl でも実行してみりゃわかりよいかも


227 :仕様書無しさん:2001/05/07(月) 22:48
ネタとしか思えない箱氏の蒸し返し発言が始まったよ。
同じこと何回も何回も何回も何回も何回も何回も。
一つの事にこだわると他の事を学べないのかこの人は!


228 :仕様書無しさん:2001/05/08(火) 10:35
元々は「そういう時もあるんですね」で済む程度の内容なのにね。
どうせcでmallocを使って、freeのコストが大きいコードは書いて
いないのだろうから、気にしなきゃいいのに。

229 :仕様書無しさん:2001/05/08(火) 14:41
>>228
自分で判断できないから、他人に同意を求めようとしているんだけど
煽られているうちに目的を見失ってしまった様子。

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

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


231 :仕様書無しさん:2001/05/09(水) 22:55
プログラマが賢くちゃいけない、みたいな雰囲気です。
反知性主義的というか。
典型的なスウェットハウスじゃねーの? < 箱氏の言う「開発現場」とやら


232 :仕様書無しさん:2001/05/10(木) 13:23
スウェットハウスってなんですか?
たこ部屋とかそういうニュアンスですか?

233 :仕様書無しさん:2001/05/11(金) 02:16
ところで、free standing environment を
無視したがる人が多いのはなぜ?


234 :仕様書無しさん:2001/05/11(金) 11:41
>>233
別に無視してるわけじゃなくて、知らないだけでは?

235 :仕様書無しさん:2001/05/13(日) 02:04
>>233 >>234
特定の環境依存の話をしても無意味だからでは?


236 :仕様書無しさん:2001/05/14(月) 01:33
malloc, free, exit の話に限ればそうだよね。

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


237 :仕様書無しさん:2001/05/14(月) 01:53
つーか、malloc, free, exit の話題だよね? (藁
それ以外で >> 236 のように言い切った人は記憶にないなあ

238 :仕様書無しさん:2001/05/17(木) 07:22
箱氏、このところ木曜日になると現れるな。
次回のXデーは24日か?

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


239 :仕様書無しさん:2001/05/17(木) 07:32
ただ今、17日(木曜)朝7:30。
箱氏の投稿4件発見!へへ〜〜〜っ(ひれ伏し) > 238

240 :239:2001/05/17(木) 07:34
カキコしてから気づいたが238って俺のカキコの
ほんの直前のものだったんだね。でも自作自演じゃないぞ!

241 :仕様書無しさん:2001/05/17(木) 08:00
まだ終わってねーの?
もうfj.comp.lang.cとっくの昔に巡回からはずしたからどうでもいいけど(笑)

242 :仕様書無しさん:2001/05/17(木) 12:25
>>231
同意。



243 :仕様書無しさん:2001/05/17(木) 22:16
fjより2ちゃんねるのほうがよっぽど質が良い。
大部分が2chに流れたせいかな?


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

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

245 :仕様書無しさん:2001/05/18(金) 09:25
news読んでからなら、そんな事きっと書かないよ。

246 :仕様書無しさん:2001/05/18(金) 12:00
>>244
free() が必要ならすればいいだけの話。俺は fj の free 不要派の意見に
賛成だ。

247 :仕様書無しさん:2001/05/18(金) 12:16
>>244
> NEWS の方を読んでないから知らないけど、
要約すると「ANSI-Cならは、exit()前のfree()は不要」だ。

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

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


248 :仕様書無しさん:2001/05/18(金) 12:37
>不要
ピクッ(ワラ

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

250 :仕様書無しさん:2001/05/18(金) 15:40
>>249
> どうでもいい主張ですね。つか覚えるだけ無駄な感じ。
> なにかメリットあるの?
プログラムと同じ寿命を持つデータ構造をわざわざ解体する必要が無い。


251 :仕様書無しさん:2001/05/18(金) 16:03
>>250
その通り。malloc は必要でも free が必要ない、っていうか free する
と手間もかかり性能も深刻なまでに劣化する、というケースだってある
だろう。

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

252 :仕様書無しさん:2001/05/18(金) 16:47
結論:
片山@PFUはウザイ。

253 :仕様書無しさん:2001/05/18(金) 17:46
一般的に言って、自分の間違いを指摘されて、
ウザイで済ませるやつはクソだね。

254 :仕様書無しさん:2001/05/18(金) 20:08
>>252
おまえがな。

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

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


256 :仕様書無しさん:2001/05/18(金) 21:36
>>255
> しかし「freeしない」という回避策はありえない。もっとべつの方法を取る。
誰が全くfreeしないと言っている?
不要なfreeはしないだけ。必要なfreeはする。

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


257 :仕様書無しさん:2001/05/19(土) 00:29
あいつら所詮Cどまりの厨房。
これ以上糞コードを
ばら撒かないことを祈るのみ。

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

259 :仕様書無しさん:2001/05/19(土) 01:24
つまり動的static変数みたいな使い方?
いわれてみればこういう使い方したいときあるなぁ

260 :仕様書無しさん:2001/05/19(土) 01:38
ここがドカタCプログラマのすくつでちゅか〜

261 :仕様書無しさん:2001/05/19(土) 15:59
>>253-254
俺がどうなのかはさておいて、絶対評価すれば片山@PFUと鶴田はウザいぞ。
具体的に言えば、彼らは、粘着質で、社会的常識に欠け、コミュニケーション
能力に著しく欠けてる。

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

262 :仕様書無しさん:2001/05/19(土) 16:06
箱氏の発言。

<9du8tm$ro2$4@newsjp.mbn.or.jp>

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

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

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

263 :仕様書無しさん:2001/05/19(土) 16:08
片山氏の発言(箱氏へのフォロー)

<KATE.01May9145533@sims211.tokyo.pfu.co.jp>

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

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

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

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

265 :261-264:2001/05/19(土) 16:15
更に付け加えると、俺自信は粘着質で、ウザい、コミュニケーション不全な
社会人失格人間だよ。俺を貶めても何にもならないよ(w

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

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


267 :仕様書無しさん:2001/05/21(月) 13:15
鶴田の発言(と俺のコメント)。

<9d9d63$1dsd$1@nwall2.odn.ne.jp>

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

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

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

氏ね。

268 :仕様書無しさん:2001/05/21(月) 13:17
さて、鶴田は
<9dbsok$2uoj$1@nwall1.odn.ne.jp>

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

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

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

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


270 :261:2001/05/21(月) 14:56
>>269
うむ、箱氏もウザいのは同意。
Sugihara氏は論外。

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

271 :仕様書無しさん:2001/05/21(月) 15:17
>>258
全く同意見。



272 :仕様書無しさん:2001/05/21(月) 16:36
> 最近参戦してきた奴も

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

273 :仕様書無しさん:2001/05/21(月) 17:39
>>271
>>>258
>全く同意見。

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

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

274 :仕様書無しさん:2001/05/21(月) 17:54
>>273
> そうじゃ
> ないシステムを作ってる人たちも大勢いるんだよ。
> 何ヶ月もノンストップのサーバアプリでね。
あっそう。だから?
そんなことを告白してなにが言いたいの?

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

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

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

275 :仕様書無しさん:2001/05/21(月) 18:02
>>274
>> 自分達が見えてることだけを基準に物を言わないこと。
>>オマエモナー

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

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

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

276 :仕様書無しさん:2001/05/21(月) 18:03
>>274
>アホをアホと言わないでっていうお願い?
>僕をバカにしないでっていう懇願?

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

277 :仕様書無しさん:2001/05/21(月) 18:30
先週末から今週にかけて、レベルの低い厨房が跋扈し始めたな。

278 :仕様書無しさん:2001/05/21(月) 18:56
>>273
>自分達が見えてることだけを基準に物を言わないこと。

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

279 :274:2001/05/21(月) 19:07
>>275
> 論理的思考が出来ないみたいだね。
論理的発言をしてない奴に言ってくれ。

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

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

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

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


280 :仕様書無しさん:2001/05/21(月) 19:35
>>274
アホクサ。

281 :仕様書無しさん:2001/05/21(月) 19:39
>>279
>そうだね、そういう奴って感想しか言えなんだよな。>>277みたいに

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

282 :258 一人でマジレス:2001/05/22(火) 01:28
>>273
いや、だからさ、自分達の開発の前提条件とか要求条件から判断して「必ずfree
する」とか「フラグメンテーションの問題は考慮する必要なし」というのは
ぜーんぜん問題ないんだよ。

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

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

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


283 :258:2001/05/22(火) 01:35
悪い、俺「跋扈」って読めねえ(藁
俺ってレベルの低い厨房以下?

284 :273:2001/05/22(火) 10:28
258、あなたいい人だよ。心が洗われたね。

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

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

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

285 :仕様書無しさん:2001/05/22(火) 12:46
>>284
わたくしも同意するであります。


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

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

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


287 :仕様書無しさん:2001/05/22(火) 15:44
>>286
おまえ馬鹿だろ。
つーか、日本語読めないんだろ。

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

288 :274:2001/05/22(火) 16:21
>>287
> おまえ馬鹿だろ。
> つーか、日本語読めないんだろ。
呼ばれもしないのにのこのこやってきて
無理してくだらない煽りをする>>286は馬鹿だろ?
つーか羞恥心がないんだろ?

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

# もっと酷く煽るぞ


289 :仕様書無しさん:2001/05/22(火) 16:26
集合を知らないと、否定を肯定と取れてしまうんですね。

290 :仕様書無しさん:2001/05/22(火) 17:24
>>288
おまえ、誰かと誰かを混同してるみたいだけど、俺が言いたいのは

バカはしゃべるな

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

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

291 :274:2001/05/22(火) 17:43
>>290
> バカはしゃべるな
じゃあなんでお前がだまらないの?
それもわからんバカなのか。

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

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

292 :仕様書無しさん:2001/05/22(火) 18:28
>>291
おまえこのスレで一体何を語ったんだ?
何番の発言?

293 :仕様書無しさん:2001/05/22(火) 18:29
>>291
おまえ、他のスレも荒らしてるだろ。
いいかげんヤメレ。

294 :274:2001/05/22(火) 20:02
>>292
> おまえこのスレで一体何を語ったんだ?
>>273はワケワカランって語った。
だいたいfree on exitとフラグメントは別問題だろ?
O田氏の言葉を借りて言えば
「原則freeしてフラグメントが発生しなければ
 free on exitしてもフラグメントが発生しないだろう」

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

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

295 :273:2001/05/22(火) 20:13
>>>273はワケワカランって語った。
>だいたいfree on exitとフラグメントは別問題だろ?

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

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

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

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

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

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

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

296 :273:2001/05/22(火) 20:15
さぁ、流れもわかったところで、>>258 -> >>273の流れで、
何か意義のあることを言いたいなら言ってくれ。

297 :273:2001/05/22(火) 20:19
それから暇があったら、>>282 -> >>286で、もう一度
286の内容を説明してくれよ。

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

298 :274:2001/05/22(火) 21:00
>>295
> >だいたいfree on exitとフラグメントは別問題だろ?
> へ?そんなことは判ってるよ。
これさえ意見が同じなら別に意見などない。

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

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

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


299 :274:2001/05/22(火) 21:09
>>297
> 箱に対して言ってるだろ。
> 奴は自分の範囲での前提条件を一般的な前提条件に摩り替えようとしてる。
これのことか?

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

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


300 :258:2001/05/22(火) 22:07
おー、なんかみんな楽しそーに煽りまくってるじゃん。俺も混ぜてよ。
馬鹿! 黙れ! 厨房!! 跋扈!!(早速使ってみた)

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

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

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


301 :仕様書無しさん:2001/05/22(火) 23:32
おめーらfjに帰れよ。
ここはfjの厨房どもを晒し者にするスレなんだからさ。

302 :仕様書無しさん:2001/05/23(水) 09:15
今まで大丈夫だったから大丈夫ってやつだな。

303 :273:2001/05/23(水) 09:40
>>298
やっとわかってくれたようで俺はうれしいよ。

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

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

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

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

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

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

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

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

304 :273:2001/05/23(水) 09:47
追記。

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

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

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

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

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

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

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

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

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

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

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

307 :仕様書無しさん:2001/05/23(水) 17:28
SugiharaはCL.EXEを使っているという意識はないんだろうなぁ。

308 :258:2001/05/25(金) 00:57
>>305
了解了解。なら言ってることは同じだね。

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

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

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

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


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

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

#Sugihara は別。


310 :223その他:2001/05/25(金) 19:06
>>261-265
あなたが人間的に認めようが否定しようが、技術屋の能力や
議論の中身(論理的・技術的な正しさ)とは何の関係もない。
あなたは世界の中心に位置して論理の正しさを支配する神ではないんだ。
目を覚ませ。

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

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


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


311 :223その他:2001/05/25(金) 19:09
追加じゃ。
Sugihara はもうどっか行って欲しいな。
闘牛場に紛れ込んだ犬みたいでウゼー。

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

312 :261:2001/05/25(金) 20:11
>>310
あのさ、俺が引用した発言が、君が言う「議論」足りえるとでも言いたいの?

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

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

>目を覚ませ。

何からさ。

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

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

んで、君は何が言いたいの?
サパーリわからん。

313 :仕様書無しさん:2001/05/25(金) 20:26
なまをです。
あれは私の息子です。
ああ見えても素直な子なんですよ。


314 :223その他:2001/05/26(土) 14:29
>>312
> >目を覚ませ。
> 何からさ。

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

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


315 :C初級者:2001/05/26(土) 17:23
ここのスレ見て話題のニュース購読してみたんですが、
そんなに議論しなくてはいけない内容なのでしょうか?
話の中身以前に議論の目的自体が疑問でしょうがないのですが?

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

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

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

317 :仕様書無しさん:2001/05/26(土) 21:21
>>315
でも議論の発端自体はそんなに変じゃなかったんだけどな。
素朴な初心者の質問に答えていただけ。

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

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

318 :仕様書無しさん:2001/05/26(土) 22:52
でも、いつのまにか「必ずフリーしろといっているわけではない」に
かわってますよね。だから、もう終わっていいはずなんだけど、箱に
切れちゃった片山に箱が応戦している状態が続いています。

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

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


321 :仕様書無しさん:2001/05/27(日) 03:39
>319

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

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

C FAQ 読めって感じだよ。


322 :223その他:2001/05/27(日) 05:20
>>321
むむ、そんな記事記憶にない。message-ID 教えてちょ。

323 :C初級者2:2001/05/27(日) 07:22
結論としては、どうすべきなのですか?
free()しないほうがいいのですか?

324 :仕様書無しさん:2001/05/27(日) 07:37
mallocしたらfreeする。
それができないようなケースでは
(こういうのは全体の割合でみたらレアケース)
malloc/freeの代替案を探す。
そしてもうfj.compには関わるな。

325 :仕様書無しさん:2001/05/27(日) 14:56
>(こういうのは全体の割合でみたらレアケース)

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

326 :仕様書無しさん:2001/05/27(日) 15:00
もうageるなよ。基地外はfjに帰れ。

327 :仕様書無しさん:2001/05/27(日) 15:09
>>326
おまえがな。(藁

328 :仕様書無しさん:2001/05/27(日) 15:56
>>327
チミだと思うが


329 :仕様書無しさん:2001/05/27(日) 16:09
お約束で
ドッチモナー

330 :321:2001/05/27(日) 16:46
>322
今 galaxy で検索したら、リアルタイムで読んだ時と文章がちがうよ。
なんか、いやな気持ちになった。


331 :仕様書無しさん:2001/05/27(日) 17:37
無能で勤勉なプログラマー
vs
有能で怠惰なプログラマー

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

332 :仕様書無しさん:2001/05/27(日) 17:53
331さらしage


333 :仕様書無しさん:2001/05/27(日) 17:57
>>332
確かにバカまるだしですな。

334 :仕様書無しさん:2001/05/27(日) 18:04
>>331
ってこたぁ、あのスレは
隊長(反原則Free)vs銃殺死体(原則Free)
って事ですかい?

335 :261:2001/05/27(日) 19:52
>>314
>などと書いてあるんで夢見てんのはあんたじゃないかと思ってね。
>「俺の嫌いな人間と同じ意見を言うやつはみんなそいつの信奉者」
>という夢。違うか?

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

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

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

336 :仕様書無しさん:2001/05/27(日) 20:49
>>335
ハァ?なんで“絶対”評価?
反論が怖いからって予防線張って自爆してるよ。

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

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

もう、いいかげん目ぇ覚ませよ(笑)


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

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

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

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

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

>もう、いいかげん目ぇ覚ませよ(笑)

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

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

338 :仕様書無しさん:2001/05/30(水) 20:20
> 俺が言ってる「絶対評価」は、俺の評価とは別に
> 彼らを評価しろ、っていうことだ。

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

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

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

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

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


339 :仕様書無しさん:2001/05/30(水) 20:23
追記。
>俺を貶めて悦に入りたいの?

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

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

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

340 :261:2001/05/31(木) 13:25
君の書いている文章を読むと、ほんとここが2chなんだなー、って思うよ。

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

341 :261:2001/05/31(木) 13:28
>もし「貶められた」状況にあんたがあるとしたら、
>その材料を提供したのはあんたのカキコ自体だ。

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

342 :仕様書無しさん:2001/05/31(木) 13:28
>>340
> それ以上でも以下でもない。内容無いし。
オマエモナー(そう思うんだったらsageろ)


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

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

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

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

345 :261:2001/05/31(木) 13:35
>>342
>> それ以上でも以下でもない。内容無いし。
>オマエモナー(そう思うんだったらsageろ)

俺に煽って欲しいの?
粘着だよ?俺って(藁

346 :261:2001/05/31(木) 13:45
>>338
最近のfj.news.usageとかjapan.yosoを読んでみなよ。
鶴田の電波ぶりが堪能できるから。

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

347 :ばーか:2001/05/31(木) 13:45
>>345
はやく煽れよ(プ

348 :仕様書無しさん:2001/05/31(木) 13:54
>>346
> ひょっとして、君、鶴田?
じゃあひょっとして、君は箱ですか?

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


349 :専卒PG:2001/05/31(木) 16:54


    ∧ ∧     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    ( ゚Д゚) 目<  ケンカをやめてぇ〜♪
     |つ つ ||  |  ふたりを止めてぇ〜♪
   〜   |  .||  \_____________
    ∪ ∪  .||




350 :仕様書無しさん:2001/06/01(金) 09:42
おお、止まった(w

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

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

352 :仕様書無しさん:2001/06/01(金) 15:48
Sugihara氏に対する片山氏のフォロー

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

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

353 :仕様書無しさん:2001/06/01(金) 15:50
箱氏に対する片山氏のフォロー。

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

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

354 :仕様書無しさん:2001/06/01(金) 16:03
もともとの鶴田氏の主張。(途中の引用部は箱氏のもの)

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

箱氏の鶴田氏への質問。

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

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

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

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

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

鶴田氏の答。

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

*

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

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

355 :仕様書無しさん:2001/06/01(金) 16:09
鶴田君って、自分の日本語能力をきちんと把握してるみたいだから、
なるべく長文は書かないようにしてるみたいだね。

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

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

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

356 :仕様書無しさん:2001/06/02(土) 04:43
>>355
>郷愁を(?)誘うね
君の田舎はこんな人ばかりなのか? (w

357 :仕様書無しさん:2001/06/04(月) 09:10
>>356
なにいってんの?
君、やっぱり、鶴田なんだろ。

文章のダサさかげんがママだよ(プ

358 :仕様書無しさん:2001/06/05(火) 16:03
Sugihara Yoshimi うざい。

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


359 :仕様書無しさん:2001/06/05(火) 21:31
他人は全て同一人物で鶴田かよ。粘着はさっさと病院逝け。

360 :仕様書無しさん:2001/06/05(火) 21:38
>>357
「郷愁」という言葉に >>356 は反応したものと思われ。
知らない言葉だったら無理して使わないほうがよいと思う。

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

361 :仕様書無しさん:2001/06/05(火) 21:52
結局、粘着=箱だったの?
粘着のいってる内容って何?
引用並べてコメントすること?
サパーリわかんねえ。

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

362 :仕様書無しさん:2001/06/06(水) 16:22
>結局、粘着=箱だったの?

ちゃう。

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

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

363 :仕様書無しさん:2001/06/06(水) 17:22
鶴田氏の発言(引用部分はSugihara)。

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

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

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

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

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

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

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

364 :仕様書無しさん:2001/06/06(水) 17:27
Sugiharaは言うまでも無く、片山氏や鶴田氏や、箱氏にさえも
はるかに劣るけど(ワラ

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

365 :仕様書無しさん:2001/06/06(水) 23:32
>>363
だーかーらー郷愁ってなんなのよ。私も >>356 同様
「あんたの故郷はそういう奴ばっかりだったのか?」
との疑問が頭を離れません(苦笑)
「憐憫の情を誘う」とかだったら文意が繋がるんだけど。

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


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

366 :仕様書無しさん:2001/06/07(木) 00:03
箱氏、japan.comp.windows2000やjapan.handmade.compじゃ普通なんだけどな。
なんであんなんになっちゃったのか。

367 :仕様書無しさん:2001/06/07(木) 11:31
また箱がどっさり投稿してきましたな。

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


368 :仕様書無しさん:2001/06/07(木) 11:57
あげるな

369 :仕様書無しさん:2001/06/07(木) 12:50
>>368

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


370 :ヲッチャー:2001/06/07(木) 13:18
>>365
>だーかーらー郷愁ってなんなのよ。私も >>356 同様
>「あんたの故郷はそういう奴ばっかりだったのか?」
>との疑問が頭を離れません(苦笑)

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

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

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

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

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

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

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

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

371 :ヲッチャー:2001/06/07(木) 13:22
俺が鶴田氏を嫌ってるのは、ある人に対して、最初は尊敬語や丁寧語で
語りかけて、あとから態度をコロッと帰るところなんだ。

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

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

俺はそれがイヤなんだ。

372 :fj.comp.lang.c:2001/06/07(木) 13:40
漏れも鶴田の書き出しが嫌い。

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

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

374 :苗字@会社:2001/06/07(木) 14:25
 C Language的には、
「処理系依存(核爆)」
だろ!!


375 :仕様書無しさん:2001/06/07(木) 16:37
age荒らし逝ってよし

376 :仕様書無しさん:2001/06/07(木) 17:05
>>373
マネだったノカー!ますます恥ずかしいね(w

377 :365:2001/06/07(木) 17:58
>>370
郷愁の意味は判ったので了解。
個人の内部で完結してる連想に噛み付きゃしません。

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

378 :ヲッチャー:2001/06/07(木) 22:01
松本登場!

箱氏に対するフォロー。

<uelsw6fpy.fsf@news.fin.ei.nsc.co.jp>
> 相変わらず日本語に不自由してますね.

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

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

379 :ヲッチャー:2001/06/07(木) 22:05
松本 洋暁の箱氏へのフォロー

<u8zj46en7.fsf@news.fin.ei.nsc.co.jp>
> 相変わらず文脈が読めないですね.
...
>> # 混乱させたいだけ ?
>
> 箱さんがそうだというのはわかりました.

なんだ?こいつ。

380 :ヲッチャー:2001/06/07(木) 22:13
橋本 剛 登場!

誰か、
<snmpucg210r.fsf@indra.spp.hpc.fujitsu.co.jp>
について、解説してくれ。長くて読めん。

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

382 :仕様書無しさん:2001/06/08(金) 09:16
アホやバカを見つけると突っつきたくなる人は良くいますよね。

383 :ヲッチャー:2001/06/08(金) 09:33
>>381
といいつつageてるじゃん、鶴田君(ワラ
本物(?)登場により、鶴田君を叩くのはしばらく控えるよ。

384 :仕様書無しさん:2001/06/08(金) 10:18
本人がここで watch されていることを投稿したようなので、
更に数人流れてくるかもしれませんね。

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


385 :ヲッチャー:2001/06/08(金) 12:02
ほぉ、本人だったのか。

リンクを張られても尚、

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

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

386 :Sugihara Yoshimi大好き(はぁと:2001/06/08(金) 12:56
>>384
ゴルァ!!!好きなスレだから俺は上げるぞゴルァ!!!ヽ(`Д´)ノ

387 :仕様書無しさん:2001/06/08(金) 13:17
もうネタはいいよ。

388 :仕様書無しさん:2001/06/08(金) 13:18
>>385
今時2chをUGだと思ってる奴なんているのか?

389 :ヲッチャー:2001/06/08(金) 13:29
いるでしょ。

つ ー か a g e ん な。

390 :仕様書無しさん:2001/06/08(金) 16:14
>>383
> 叩くのはしばらく控えるよ。
ヘタレ野郎だな。
2chでこっそり叩いてて、本人出てくると遁走かい?


391 :ヲッチャー:2001/06/08(金) 16:42
>2chでこっそり叩いてて、本人出てくると遁走かい?

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

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

392 :ヲッチャー:2001/06/08(金) 16:46
>>390
>ヘタレ野郎だな。
>2chでこっそり叩いてて、本人出てくると遁走かい?

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

393 :仕様書無しさん:2001/06/08(金) 17:07
Sugihara Yoshimi がこのスレを「面白かった」だってよ...
例によって、ここでも何を議論しているのかが理解できないのか (w



394 :390:2001/06/08(金) 17:19
>>391-392
> 最初から俺はそういう奴だと表明してるじゃん。
知らんかった、粘着と表明しているのは知っていたが?
粘着だったら遁走しないで本人とやりあえよ。見てるから。

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

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

# さっぱりわからない

395 :Sugihara Yoshimi大好き(はぁと:2001/06/08(金) 19:16
>>393
俺もその記事読んだよ。その一言だけだったね。案外自分の無知・厨房・ドキュソ
っぷりに気づいて愕然としていたりして…。

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

396 :仕様書無しさん:2001/06/08(金) 21:22
鶴公も二度とあのくさい登場の仕方すんなよな。
わかったな、鶴!返事しろ!(藁

397 :365:2001/06/08(金) 22:12
大幅に出遅れたな…
本人登場しちゃあまり美味しくないよ、このスレ。

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

398 :SYN:2001/06/09(土) 07:06
||  ∧ ∧
||  ミ・ο・ミ  はにゃーん
||〜(,,uuノ
~~~~~~~~~~~~~~~

399 :仕様書無しさん:2001/06/09(土) 08:33
もう旬は完全に過ぎちゃったけど、
コッソリとヲッチャーは Sugihara だった説を提唱してみる。

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


400 :仕様書無しさん:2001/06/09(土) 10:46
>399
それおもしろい。そういうことにしよう。
つーか、あんがいあたってそう。

401 :仕様書無しさん:2001/06/10(日) 07:57
んでよ〜結論としては
「いみないことに時間かけてるよ」
でいいのかね?
明日までレポートにしなくちゃいけないから。

402 :仕様書無しさん:2001/06/10(日) 12:48
free 必須派の言う(実はどうにも半端な)再利用をするつもりがないなら、
malloc-free の対称性なんぞ気にしなくてよいのでは。

403 :ヲッチャー:2001/06/10(日) 14:49
>>399
>コッソリとヲッチャーは Sugihara だった説を提唱してみる。
ちゃうよ。

404 :ヲッチャー@aa1999060325007.userreverse.dion.ne.jp:2001/06/10(日) 14:49
うお、失敗。再度。

405 :ヲッチャー:2001/06/10(日) 14:51
>>394
>実名で投稿していてリスクも自分で負っているfjだと侮蔑的発言は許されなくて、
>匿名で書き込んでいて安全地帯の2chだと侮蔑的発言は許されるの?

さぁ?そんなこと自分で考えたら?(ワラ

406 :ヲッチャー:2001/06/10(日) 14:54
>>399
>技術的な中身に踏み込まないスタイルが似てる。

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

407 :ヲッチャー:2001/06/10(日) 14:56
ちなみに、ここで鶴田氏へのコメントをやめるというのは、彼が

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

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

# 今日の冒頭の発言でageてしまって、スマソ

408 :ヲッチャー:2001/06/10(日) 14:58
ああ、それから俺がここで技術論に踏み込まないのは、
fj.comp.lang.cの書き込み全部をフォロー(意味通じるよね)
してるわけじゃないから。

そんな暇ないよ〜ん。

409 :ヲッチャー:2001/06/10(日) 15:01
>>390
>粘着だったら遁走しないで本人とやりあえよ。見てるから。

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

君こそヘタレ〜(ワラ
君こそヘタレ〜(ワラ

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

410 :仕様書無しさん:2001/06/10(日) 15:06
ヲッチャーうざい。age んなって言う前に、自分の言いたいことを
まとめてから書き込めよ。短時間に6連続書き込みすな。

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

411 :ヲッチャー:2001/06/10(日) 15:24
>>410
>sageろ、sageろって言うなら、自分の web でも開いてそこで
>やってくれな。

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

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

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

412 :仕様書無しさん:2001/06/10(日) 15:33
なんだかんだ言っても、連続発言ばっかりしてるのはイタイな。


413 :仕様書無しさん:2001/06/10(日) 15:49
誰かキチガイ警報のコピペ頼む。

414 :仕様書無しさん:2001/06/10(日) 21:23
 ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ
   へ  )   へ  )   へ  )    へ  )   へ  )   へ  )   へ  )   へ  )   へ  )
      >      >      >       >      >       >       >      >       >
┌───────―――――――――――――─────────―――――――――──┐
│      ( ゚ ∀゚ )            ( ゚ ∀゚ )                    ヽ( ゚ ∀゚ )ノ    |
│   ( ゚ ∀゚ )               最大級キチガイ警報!!!!!!      (  へ    |
|           ( ゚ ∀゚ )           ( ゚ ∀゚ )        ( ゚ ∀゚ )      く      |
└―――──――――――――――――――――――――──―――――――――――――┘
  ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ ヽ(゚ ∀゚ )ノ
   へ  )   へ  )   へ  )    へ  )   へ  )   へ  )   へ  )   へ  )   へ  )
      >      >      >       >      >       >       >      >       >




415 :仕様書無しさん:2001/06/11(月) 12:21
おい、まだfjで続いてるよ。
しかもとっくに論破された内容の延々くり返し。
箱まじうぜぇ。


416 :仕様書無しさん:2001/06/11(月) 13:47
だからリピート病だって。Sugihara は知ったか病な。
もうあの二人は fj.comp.lang.c の東洋海亀(Naoya Kinjo)なんだよ。


417 :仕様書無しさん:2001/06/11(月) 16:10
Sugiharaあいかわらず痛すぎ
「面白かったです」で自覚してくれたかという期待もはかなく

418 :仕様書無しさん:2001/06/12(火) 00:17
論理的に考えられない人間に、論理的に説明して何になるんだろう。
時間の無駄と思うんだが、彼らに何か得るものがあるのだろうか。


419 :仕様書無しさん:2001/06/12(火) 02:15
>>418
しかし fj.comp.lang.c は論理的な話をするところだからねえ。
非論理的な投稿に占拠されるわけにいかないんじゃない?

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

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


420 :仕様書無しさん:2001/06/12(火) 03:13
freeくらい書け糞どもが

421 :仕様書無しさん:2001/06/12(火) 04:06
free書いちゃいけないときってあるの?
とりあえず全部freeしてるけど。

422 :仕様書無しさん:2001/06/12(火) 04:26
>>420, >>421
fj.comp.lang.c くらい読んでから出直して来なさい!


423 :仕様書無しさん:2001/06/12(火) 04:43
それが面倒だから聞いてるのby厨房

424 :仕様書無しさん:2001/06/12(火) 07:51
>>423 厨房は逝ってよし(これで満足いただけたかな?)

425 :仕様書無しさん:2001/06/12(火) 10:48
論理的にものを考える人は、相手も論理的にものを考えると勝手に仮定し
ていますが、これは常に正しいわけではありません。
この仮定が成り立つのは、感覚的には5割ぐらいでしょうか。

426 :仕様書無しさん:2001/06/12(火) 19:21
<相手も論理的
人にもよるし、話題にもよる。

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

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

427 :ナーナス:2001/06/13(水) 00:13
>>56
> malloc/free論争って要するに規格を拡大解釈することを良しとするかしないかを争ってるんですよね?

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

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

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

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


428 :仕様書無しさん:2001/06/13(水) 01:53
>>427
fjから流れてきたの? いちおう最後までスレ読めば?

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

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


429 :仕様書無しさん:2001/06/13(水) 09:34
> 実名じゃないのに引っ込みつかん

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

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

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

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

430 :仕様書無しさん:2001/06/13(水) 09:53
>>429
> 「goto 禁止」と同程度、「初心者のうちに済ましとけよ」レベルだと思う。
えっ、「ハンガリアン記法」と同じで「根拠レスの精神論」レベルだと思ってた。


431 :仕様書無しさん:2001/06/13(水) 11:47
>>430
そっちでもいいよ。
「済ましとけ」なのは、はしかみたいなもんだと思ってるから。
はやめにかかって直ればよし。でも長年やっててかかると…

432 :仕様書無しさん:2001/06/13(水) 11:58
>>429
え?malloc-free対称を用心して守っておけばリーク予防になるんじゃないの?

433 :仕様書無しさん:2001/06/13(水) 12:08
>>432
まだいたよここにも。
fj読めば。それかfjで訊け(藁


434 :仕様書無しさん:2001/06/13(水) 12:43
>>433
何でならないの?
つーか、君fj読んでないだろ。それとも書かれてる内容が理解できんのか?

435 :仕様書無しさん:2001/06/13(水) 13:06
>>434
読んでるよ。去年のもね。

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

436 :仕様書無しさん:2001/06/13(水) 14:27
何でならないのか、説明してみろよ。

437 :仕様書無しさん:2001/06/13(水) 14:30
freeが必要ならする。必要ないならしない。
どこに「原則」とか「デフォルト」の入る余地があるんだろ?

438 :仕様書無しさん:2001/06/13(水) 14:35
>>436
対称ならスタック使えば? その方がよっぽどいいっしょ。
つーか、exit前のfreeにリーク関係ないじゃん。


439 :仕様書無しさん:2001/06/13(水) 14:47
>>438
おいおい、誰がexit前のfreeの話をしてるんだよ。
「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
を話してるんだよ。

440 :仕様書無しさん:2001/06/13(水) 14:56
>>438
パンがなければケーキか。
んで、小麦粉はどこから持ってくるのかな?

441 :仕様書無しさん:2001/06/13(水) 14:56
なんだ。じゃあfjとは関係ない話だね。
漏れは予防にはならないと思うけど、まあ勝手にすれば?


442 :仕様書無しさん:2001/06/13(水) 15:02
>>441
うーん、その「ならないと思う理由」を聞きたいんですが。

443 :仕様書無しさん:2001/06/13(水) 15:23
>>439
> 「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
mallocで構築するデータに対称性があるならリーク予防になるだろう。

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


444 :仕様書無しさん:2001/06/13(水) 15:30
>>443
対象性のあるデータってどういうものですか?

445 :仕様書無しさん:2001/06/13(水) 15:31
>>429
だって、組込系はほとんどの場合exitしないぞ。
それどころか、一度プロセスが動き出したらユーザが電源切るまで
動き続けてたりするんだもん。


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

447 :仕様書無しさん:2001/06/13(水) 15:33
今度は2chで論争ですか。
頭悪いんですか?
ま、せいぜいsageで罵り合っててください。

448 :仕様書無しさん:2001/06/13(水) 15:34
なんかさfjの議論で「必要なのにfreeしない厨房」が増えたような気がしない?
>>443とかもわかったようなこと書いてるけど、微妙にはずしてるし。

449 :仕様書無しさん:2001/06/13(水) 15:36
>>447
ははは、反論できずに逆切れですか。
いいですな、2chでは逃げが打てて(藁

450 :仕様書無しさん:2001/06/13(水) 15:44
exitするプログラムしか書かない奴と、exitをしないプログラムしか
書かない奴との争いだったんだ。

451 :仕様書無しさん:2001/06/13(水) 15:59
んだから場合によるんだから「原則」なんぞにするなってこと。

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


452 :仕様書無しさん:2001/06/13(水) 16:10
>>451
ん、誰も「原則」なんて持ち出してないよ。

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

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

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

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

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

453 :仕様書無しさん:2001/06/13(水) 16:29
>>452
メモリ領域のスタックと思われ

454 :仕様書無しさん:2001/06/13(水) 16:33
そのメモリ領域がスコープ外でも有効である必要がある場合は少なくないと思うが。

455 :仕様書無しさん:2001/06/13(水) 16:35
>>452
もーfj.comp.lang.cの中身を繰り返すのはめんどくさい。

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

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


456 :仕様書無しさん:2001/06/13(水) 16:50
>ほんとに対称性を保てる場合ならスタックで十分でしょ

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

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

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

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

って言ってるんだけど。
なるの?ならないの?

457 :仕様書無しさん:2001/06/13(水) 16:50
っていうか auto_ptr 使え!
〜〜〜〜〜〜〜〜終了〜〜〜〜〜〜〜〜〜〜

458 :仕様書無しさん:2001/06/13(水) 16:51
>>452
> 対象性を保てばリーク予防になるでしょ?
その通りです。

で、なんで対称性のないmalloc-freeで無理に対称性を保とうとするのでしょう?
説明して下さい。

459 :仕様書無しさん:2001/06/13(水) 16:53
>もーfj.comp.lang.cの中身を繰り返すのはめんどくさい。

fj.comp.lang.cの中身も理解していないし、人の発言も読んでないんでしょ。
んで、頑迷に「スタックで十分」「fjを読んでから出直せ」と繰り返すのみ。

もういいよ、無理しなくて(藁

460 :仕様書無しさん:2001/06/13(水) 16:54
>で、なんで対称性のないmalloc-freeで無理に対称性を保とうとするのでしょう?
>説明して下さい。

話が逆。
malloc-freeを対象性を保ってつかう ⇒ リークの予防になる
という話をしてるの。


461 :仕様書無しさん:2001/06/13(水) 16:56
>>457
C言語の話なんですが・・・。

462 :仕様書無しさん:2001/06/13(水) 17:01
>>460
話が逆だろ。
わざわざ対称性のないmallocとfreeを対称に使う努力するぐらいなら
もともと対称なスタック使えば。

463 :仕様書無しさん:2001/06/13(水) 17:02
malloc()とfree()は対象性があるとでも言って欲しいのだろうか。

464 :仕様書無しさん:2001/06/13(水) 17:06
>>456 >>459
この人Sugiharaと同じこと言ってる(プ
news:97vf4m$e20$1@news.kyosai.or.jp


465 :仕様書無しさん:2001/06/13(水) 17:06
>>460
処理系依存になるがallocaを使うか、
C99の可変長配列でも使え
〜〜〜〜〜〜〜〜終了〜〜〜〜〜〜〜〜〜〜


466 :仕様書無しさん:2001/06/13(水) 17:08
>>462
>>432-435 で、笑われたからここまで引きずってるんだよ。

誰もmallocとfreeは対象性があるなんて言ってないよ。

>もともと対称なスタック使えば。

俺は一貫して「対象に」を副詞で使ってるけど、君は形容詞だと
思ってるから話がずれるんだよ。

スタックの話は君から言い出したことだけど、「スタックで十分」じゃ
ないから、mallocを使うと言ってるのがわからない?
スタックで十分じゃない場合を想像できないとかか?

467 :仕様書無しさん:2001/06/13(水) 17:12
>>464
だから何?
間違ったこと言ってると思ったら反論してみろよ、クズが。

468 :仕様書無しさん:2001/06/13(水) 17:14
誤字ネタじゃなかったの?
んじゃ「対象性」ってなに?


469 :揚げ足煽り:2001/06/13(水) 17:14
> 誰もmallocとfreeは対象性があるなんて言ってないよ。
うん、誰も「対象」なんて言っていないね。
# 「対称」とはいっているが。

> 俺は一貫して「対象に」を副詞で使ってるけど
「対象」と書いてあるメッセージID(レス番号)を示して下さい。


470 :仕様書無しさん:2001/06/13(水) 17:18
>>467
だからfj.comp.lang.cで終わった話をくり返すなっつーの。


471 :仕様書無しさん:2001/06/13(水) 17:21
対称の間違いでした。
でも、この変換ミスは致命的な瑕疵とはならないと思うけど。
ということで、>>466から続けてくれ。

472 :仕様書無しさん:2001/06/13(水) 17:23
>>470
またまた反論できないんだね。
人の言葉を借りずに、自分の言葉で何か言ったら?

473 :仕様書無しさん:2001/06/13(水) 17:27
要するにアレだ。
fj.comp.lang.cをちょっと齧った厨房が、malloc-freeをペアで使うことさえ
罪悪だと思ってしまってるんだろ?
「対称性を保って使う == ペアで使う」
だよ。本気で解らなかったのか?

474 :仕様書無しさん:2001/06/13(水) 17:29
>>472
マジでfj読んでから言ってるの?
だってこの先fjにあったのと同じ受け答えをくり返すのはうざいし。

fjで終わった(Sugiharaと、あと誰かもう1人が負けて黙った)先から続けてくれない?


475 :仕様書無しさん:2001/06/13(水) 17:36
>>474
>あと誰かもう1人
片岡だろ。「対」とか「ペア」とか言い続けて砕け散った(ワラ

ここで「ペア」蒸し返そうとしてるやつがいるし(ワラ


476 :仕様書無しさん:2001/06/13(水) 17:37
>>474
はぁ?
だから俺が間違ったこと言ってると思うなら反論しろよ。

まずは何が間違ってかから挙げてみろ。

477 :仕様書無しさん:2001/06/13(水) 17:38
つーか、お前ら俺の書き込みを読んでないんだろ。

単語に脊髄反射するんじゃねーよ。

478 :仕様書無しさん:2001/06/13(水) 17:41
> 「malloc-free対称を用心して守っておけばリーク予防になるのかならないのか」
リーク予防になる

しかし、「malloc-freeは常に対称になるとは限らない」
でいいのか?


479 :仕様書無しさん:2001/06/13(水) 17:45
>>476
反論はfjに出てたよ。3月頃。

>>477
読んでるよ。fjとおんなじに見える。
違うとこがあるなら、そっからやれば?
(fj読んだんならどこが違うか言えるでしょ?)

480 :仕様書無しさん:2001/06/13(水) 17:45
・寿命がスコープ外に及ぶ
・サイズも個数も実行時に決定
・exitしない

というケースはそんなにレアですか?

481 :仕様書無しさん:2001/06/13(水) 17:46
>>478
いいよ。

>しかし、「malloc-freeは常に対称になるとは限らない」

これにちょっと追加。
mallocとfreeは対称性があるものでも、対象性を保って使わなければ
ならないものでもない。

ただ、対象性を保って使える場面は数多く存在するし、
そういう場合に対象性を保って使っておけばリークの
予防になると言ってるんだけど、そんなに解りずらい
文章だったか?

482 :仕様書無しさん:2001/06/13(水) 17:47
>>479
おいおい、俺の発言に対する反論がfjに出てるワケないだろうが。

俺の発言で誤っている個所を指摘しろって言ってるんだが、わからんか?

483 :仕様書無しさん:2001/06/13(水) 17:54
スタック、スタックとお題目を唱えてる>>462は、スタックが無限であると思っているし、
再帰も使ったこと無いと思われ。

484 :仕様書無しさん:2001/06/13(水) 17:56
>>482
あーもーめんどくせーなー。
「あなたさまの発言とそっくり同じ内容の発言がたびたびfj.comp.lang.cに出てました。それはきれいに言い負かされてました。いちいち同じやり取りをここで繰り返すのはうざいです。もしちょっとでも新しい内容があるならそこから始めてくださいませ。」

これでいいか?

485 :仕様書無しさん:2001/06/13(水) 17:59
>>484
馬鹿か、お前。それともほんとに日本語読めねーのか?

>そっくり同じ内容の発言

俺の発言のどこがそれなのか指摘しろつってるだろーが。fjの威を借るウジムシくん。

486 :仕様書無しさん:2001/06/13(水) 18:01
>>481
> そんなに解りずらい文章だったか?
うん、解りずらい。
対称と対象が入り交じっていて(以下略)はネタとして

原因としては俺が
> 対称を用心して守っておけば
を「常に対象にできる」ニュアンスが含まれていると誤解した。
481で誤解が取れた。

君に反論しているのは俺以外に少なくともあと1人いる。
俺は消えるけどまあ頑張ってくれ。


487 :仕様書無しさん:2001/06/13(水) 18:07
>>486
>うん、解りずらい。
まぁ、推敲もせずに書き込んでるから、その辺は許してくれ。

>481で誤解が取れた。
あぁ、良かったよ。永遠に続くかと思われたよ。

>君に反論しているのは俺以外に少なくともあと1人いる。
うむ、俺も少なくとも2人を相手にしていると思ってた。
残りの一人が厨房度が高そうなんだけど、根拠無き中傷は
許さんから、徹底して相手するつもりだよ(藁

488 :仕様書無しさん:2001/06/13(水) 18:14
>>485
> 俺の発言のどこがそれなのか指摘しろつってるだろーが。
「ペアにして使うように気をつければリークが減る」
「(対称でも)サイズも個数も不明だからmalloc使う」
「(対称でも)スコープ外でも有効だからmalloc使う」

もー同じこと何度も何度も何度も何度も。
これらへの反論はfj見ろよな。(つーか、見たんだろ?なんで繰り返す?)

>fjの威を借るウジムシくん。

へえ。いまどきfjに威なんてあるの?
繰り返しがうざいだけだよーん。

489 :仕様書無しさん:2001/06/13(水) 18:15
あーもーめんどくせーなー。
やめ、やめ。厨房で結構。

490 :仕様書無しさん:2001/06/13(水) 18:21
>>48
ん、>>489は荒らしか?

>>488
>>480の発言は俺じゃないし、俺が「指摘しろ」と言ったのは>>476だ。
君の世界では、時間も狂ってるのか?

>「ペアにして使うように気をつければリークが減る」
これは確かに言った。
で、間違ってると主張するんだね?(Yes/No)

だとしたら、何か反論するか君の得意なfjでの反論のMessage-Idでも
示してみろよ。

言っておくが「ペアにして使うように気をつければ」ということに関して
議論してるんじゃないぞ。

「リークが減るのか減らないのか」だ。


491 :仕様書無しさん:2001/06/13(水) 18:21
「mallocしたらfreeが必要かどうか」を論じてるんじゃなかったのか。
そこへ「malloc使わない」というのを持ち出すのはどうかと思うが。

「目玉焼きに書けるのは醤油かソースか?」という議論の最中に、
「スクランブルエッグを食え」という発言は有効か?


492 :仕様書無しさん:2001/06/13(水) 18:23
>>488
>「(対称でも)サイズも個数も不明だからmalloc使う」
こんなこと言ってないぞ。

君の言う形容詞の対称とは、いったい何を形容してるんだい?教えてくれ。

>サイズも個数も不明だからmalloc使う

これは言ったが、何か反論でもあるのか?
まさか、mallocを使うなと言いたいわけじゃないだろうな。

493 :仕様書無しさん:2001/06/13(水) 19:48
>>485 >>492
えーと、fj でのやりとりはこちらでご覧になれますよ。

http://queen.heart.ne.jp/cgi-bin/browse?msgid=<m34rx8y6pg.fsf@maedapc.cc.tsukuba.ac.jp>
から順に「フォロウ記事」を追ってみてください。

malloc-free は宗教だと思う。


494 :仕様書無しさん:2001/06/13(水) 19:55
失敗。セミコロン挟まってた。正しくはこちら。
http://queen.heart.ne.jp/cgi-bin/browse?msgid=<97vf4m$e20$1@news.kyosai.or.jp>
http://queen.heart.ne.jp/cgi-bin/browse?msgid=<m34rx8y6pg.fsf@maedapc.cc.tsukuba.ac.jp>


495 :仕様書無しさん:2001/06/13(水) 19:59
タグ挿入防止のための仕様でしょうか。やれやれ。
自動的にセミコロン挟まってるようなので「<;」の「;」を取ってください。


496 :仕様書無しさん:2001/06/13(水) 20:11
>>493
残念ながら、その議論ではありません。
あなたも勘違いしていると思います。

俺の主張は>>490です。

さらに言えば、「いかなる場合でもmallocを使え」と主張している
わけでもありませんし、スタックを否定しているのでもありません。

・・・とかわざ言っとかないと、また>>488が勘違いするからな(藁

497 :仕様書無しさん:2001/06/13(水) 20:25
>>493
あらためてその議論を読み返してみたけど、やっぱり全然議論が
噛み合ってないね。Sugiharaにも問題があるだろうけど、前田サン
にも問題ありだ(議論の方法がね)。

すげー気持ちわるい。隔靴掻痒。



498 :仕様書無しさん:2001/06/13(水) 20:34
さてと、そろそろ帰るか(藁
488よ、何か書き込むのならまず、

>>490
>で、間違ってると主張するんだね?(Yes/No)

の答えから頼むぞ。俺はまずそれが知りたいんだ。

499 :仕様書無しさん:2001/06/13(水) 20:47
>>498
>「ペアにして使うように気をつければリークが減る」
って当然「真」でしょ。自明。
だってmalloc()に対応するfree()がなければexit-on-freeするときでない限り絶対リークするでしょ?
なんたってfree()しないんだから。
気を使おうが使うまいがしなければリークが増えますね。確実に。

500 :仕様書無しさん:2001/06/13(水) 21:21
>>497
知ったか厨房に対しては前田氏の方法で知ったかぶりを
徐々に第三者に対して明らかにするのは有効では?

知ったか本人に自覚は促せなくても第三者はそれによって
「あっこいつ知ったかだ。気ぃつけよ」と分かって有意義じゃないか。

…粘着君に似てるな、君。
快・不快原則で議論を裁こうとしてる。

501 :仕様書無しさん:2001/06/14(木) 00:29
ちっとも自明じゃないよ。>>499
そもそも「リーク」とはどういう状態を指して言っているのかが
人と場合によってまちまちだし、それによって答えも変わるし、
また『リーク』を減らすのがメリットにならない場合もある…
という議論は fj でとっくの昔に出てるんだぜ。
それをここでもう一回繰り返せってのかい?


502 :仕様書無しさん:2001/06/14(木) 00:47
>>501
そうそう。そんなかんじ。

>「ペアにして使うように気をつければリークが減る」
だから何ナノ?っていいたかった。

ついでに、ペアってどういうことさ?
前からずっと疑問に思ってた。どっかで定義されてたっけ?
malloc()とfree()が1対1対応させるということ?1対多?多対1?多対多?
スコープは?ブロック?関数?1つのファイル内?(C++なら)クラス内?プログラム全体?



503 :仕様書無しさん:2001/06/14(木) 00:51
>>502
>malloc()とfree()が1対1対応させる
malloc()とfree()を1対1対応させる

スコープにはモジュールを追加しといてくれ。すまそ。


504 :仕様書無しさん:2001/06/14(木) 01:07
>>496
全然違い分かりませんわ。
ほんとにfj読んだんかいな。

505 :仕様書無しさん:2001/06/14(木) 18:22
>>501
>そもそも「リーク」とはどういう状態を指して言っているのかが
>人と場合によってまちまちだし

えと、ちょっとお尋ねします。
メモリリークってそんなにあやふやな言葉なんですか?
僕は「システムに返却されなかったメモリ」のことだと思ってたんですが、何か他に
「メモリリーク」と呼ばれるものがあるんでしょうか?
横入りスマソ

506 :仕様書無しさん:2001/06/14(木) 18:22
リークってなあに?

507 :仕様書無しさん:2001/06/14(木) 18:24
>>502
>ついでに、ペアってどういうことさ?
>前からずっと疑問に思ってた。どっかで定義されてたっけ?
>malloc()とfree()が1対1対応させるということ?1対多?多対1?多対多?

えーと、このスレもfjもまじめに読んでないからはずしてるかもしれないけど、
ペアって1対1以外に解釈のしようがないような気がするんですが・・・。
そういうことで無い?

508 :505:2001/06/14(木) 18:27
>>506
えーと、これは僕に対する質問ですか?

509 :506:2001/06/14(木) 18:42
>>508
そういうわけではないです。リークといっても階層ごとに指すもの
が違うと思うが。

510 :仕様書無しさん:2001/06/14(木) 19:32
リークってこの議論での場合、
「ある時点でもうfree()出来ないメモリ、
つまり、ローカル、グローバルのどの変数からも参照されてないメモリ」
あたりでいいんじゃない?
それ以外のリークの意味を想定して話してる人っているのかな?

で、最終的なリークの量の上限を求めることが出来て、
なおかつその量が許容範囲内(数メガとか)なら別にfree()しなくてもいいジャン、
ってのが所謂「free()不要派」の主張じゃないかな?

対して、
「ちゃんとfree()しないとおばかプログラマ(自分含む)がバグ作りこんじゃうだろ」
ってのがfree()必要派の主張だと思ふ。

全然かみ合ってませんね(わら


511 :仕様書無しさん:2001/06/14(木) 19:42
上限を保証するため面倒な見積もりするくらいなら
freeしたほうが楽だと考えてしまう怠け者な俺

512 :仕様書無しさん:2001/06/14(木) 19:47
組込のようなサイクリックプロセスではリークを許すと上限は必ず無限大になる。

513 :仕様書なしさん:2001/06/14(木) 20:26
ヒープを自分で管理する。

514 :仕様書無しさん:2001/06/14(木) 22:01
>>512
そうだね。
そういうときはfree()しよう。
なんて単純なんだ!

>>511
それじゃ箱っちといっしょだよ。

515 :仕様書無しさん:2001/06/14(木) 22:15
1 malloc されたメモリ
→ 所有権は malloc、状態は使用中

2 malloc された後、free されたメモリ
→ 所有権は malloc のまま。状態は未使用

で、再び malloc が行われた場合は、2のメモリを優先的に割り当てるってのが
一般的な仕様ですよね。

んで、リークってのにも2つあって、例えばループの中で malloc して free
しなかったら、そのプロセスの使用メモリ量がどんどん肥大していく。それが
プロセス内でのメモリリークで、これは free することで防げる。

もう一つが、プロセスが終了した時に、malloc 所有になってたメモリが開放
されないという、システムレベルでのリーク。
「exit の前でも free しろ」ってのは後者を意識しての事だろうけど、これは
free で防げるたぐいのものではない。
free した時点で malloc 所有のメモリが OS に返る実装なら防げるが、Cの規格
ではそういう実装は要請されていないし、動作速度の点で実際そうなっていない
実装がほとんど。

よって、必要な free は省いてはいけないが、exit の直前の free は必要な
free ではない。

そういうことでしょ?


516 :仕様書無しさん:2001/06/14(木) 22:16
1 malloc されたメモリ
→ 所有権は malloc、状態は使用中

2 malloc された後、free されたメモリ
→ 所有権は malloc のまま。状態は未使用

で、再び malloc が行われた場合は、2のメモリを優先的に割り当てるってのが
一般的な仕様ですよね。

んで、リークってのにも2つあって、例えばループの中で malloc して free
しなかったら、そのプロセスの使用メモリ量がどんどん肥大していく。それが
プロセス内でのメモリリークで、これは free することで防げる。

もう一つが、プロセスが終了した時に、malloc 所有になってたメモリが開放
されないという、システムレベルでのリーク。
「exit の前でも free しろ」ってのは後者を意識しての事だろうけど、これは
free で防げるたぐいのものではない。
free した時点で malloc 所有のメモリが OS に返る実装なら防げるが、Cの規格
ではそういう実装は要請されていないし、動作速度の点で実際そうなっていない
実装がほとんど。

よって、必要な free は省いてはいけないが、exit の直前の free は必要な
free ではない。

そういうことでしょ?

ちがう

517 :仕様書無しさん:2001/06/14(木) 22:17
組込のようなサイクリックプロセスではリークを許すと上限は必ず無限大になる。

おまえのあたまのなかではな

518 :仕様書無しさん:2001/06/14(木) 22:17
リークってこの議論での場合、
「ある時点でもうfree()出来ないメモリ、
つまり、ローカル、グローバルのどの変数からも参照されてないメモリ」
あたりでいいんじゃない?
それ以外のリークの意味を想定して話してる人っているのかな?

で、最終的なリークの量の上限を求めることが出来て、
なおかつその量が許容範囲内(数メガとか)なら別にfree()しなくてもいいジャン、
ってのが所謂「free()不要派」の主張じゃないかな?

対して、
「ちゃんとfree()しないとおばかプログラマ(自分含む)がバグ作りこんじゃうだろ」
ってのがfree()必要派の主張だと思ふ。

全然かみ合ってませんね(わら

わら

519 :Gates万歳!:2001/06/14(木) 23:00
われらがゲイツ様が作られた .NET は、素晴らしいに
違いありません。
きっと世界を席巻するでしょう。

520 :仕様書無しさん:2001/06/14(木) 23:01
519 名前: Gates万歳! 投稿日: 2001/06/14(木) 23:00
われらがゲイツ様が作られた .NET は、素晴らしいに
違いありません。
きっと世界を席巻するでしょう。

こいつ馬鹿?

521 :仕様書無しさん:2001/06/14(木) 23:05
>>520
 冗談くらい分かってやれよ

522 :Gates万歳!:2001/06/14(木) 23:06
ゲイツ様のガベージコレクタは世界最強に違いありません。

うーむ、つまらん。
もう、よそう。
新しいねたになればと思ったが、資料がなかった。

523 :仕様書無しさん:2001/06/14(木) 23:08
ハァ?MALLOCなんてもう終わったんだよ?newとdeleteあればいいんだよボケども。俺様に南下もんく案の火?

524 :仕様書無しさん:2001/06/14(木) 23:11
522 名前: Gates万歳! 投稿日: 2001/06/14(木) 23:06
ゲイツ様のガベージコレクタは世界最強に違いありません。

うーむ、つまらん。
もう、よそう。
新しいねたになればと思ったが、資料がなかった。


馬鹿は馬鹿だからな

525 :仕様書無しさん:2001/06/14(木) 23:17
>>522-524
ネタは sage でな。

ちなみに、まったく面白くないぞ。

526 :仕様書無しさん:2001/06/14(木) 23:19
つーかさー「mallocしたら必ずfree」を論破するには
くだらん主張をを延々とやってないで
freeしたら破綻するような実例をたった一つageればすむことなんじゃないの?
なんかageてみろや

527 :仕様書無しさん:2001/06/14(木) 23:21
>>516
exit()後のリークはこの議論には関係ないと思うけど?
fjでもちゃんとしたmalloc(), free()ならexit()してもリークしないってのは合意されてるよね?
で、いまfjでやってるのが、「free()したほうがデバッグしやすくリークが減るので、必要」っていうけど、ほんとにそうなの?ってこと。

528 :仕様書無しさん:2001/06/14(木) 23:26
>>526
>「mallocしたら必ずfree」
誰がそんなこといってるの?(藁

529 :仕様書無しさん:2001/06/14(木) 23:28
>「mallocしたら必ずfree」
誰がそんなこといってるの?(藁

盲目?

530 :仕様書無しさん:2001/06/14(木) 23:30
ハァ?MALLOCなんてもう終わったんだよ?newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火?

ハァ?MALLOCなんてもう終わったんだよ?newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火?

ハァ?MALLOCなんてもう終わったんだよ?newとdeleteあればいいんだよボケども。俺様に南下
もんく案の火?

531 :カスは氏ね!:2001/06/14(木) 23:35
いつまで井戸端おしゃべりしてんだよ、ヴァカども(w

VBならメモリリークなんて気にする必要ねーーんだよ、ヴァカども!(w

532 :仕様書無しさん:2001/06/14(木) 23:36
かなり、話しの本質をずばりと突いていると思います。
それでは、結論としてはそのようなDQN依頼者は無視するべきなんでしょうか?
きちんと説明して、納得させて、そのような会社から500万前後の依頼料を
取れるのであれば、その話しは良い商談となったのではないかと思います。

これからは、このような零細企業でもちょっとしたソフトを導入したいと
言ってくるわけですから、そのような依頼者をどうやって扱うべきかという
問題も更に増えてくるんじゃないですか?かなり、話しの本質をずばりと突いていると思います。
それでは、結論としてはそのようなDQN依頼者は無視するべきなんでしょうか?
きちんと説明して、納得させて、そのような会社から500万前後の依頼料を
取れるのであれば、その話しは良い商談となったのではないかと思います。

これからは、このような零細企業でもちょっとしたソフトを導入したいと
言ってくるわけですから、そのような依頼者をどうやって扱うべきかという
問題も更に増えてくるんじゃないですか?

533 :仕様書無しさん:2001/06/14(木) 23:47
>>532
金のためなら、ケツの穴貸しますさん登場!(藁

534 :501:2001/06/15(金) 01:19
>>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を読み返したがらない輩が
いるようなのでな。


535 :仕様書無しさん:2001/06/15(金) 01:22
>>526
> freeしたら破綻するような実例をたった一つageればすむことなんじゃないの?
だろ? だろ? 普通そう思うよな。
でもそれをいくら挙げても、納得しないで延々ゴネてる奴がいたから
今のfjのスレッドがあるのさ。


536 :仕様書無しさん:2001/06/15(金) 01:37
とりあえず、
Windows NTではちゃんと free()しないと、プログラムが終了しても
メモリはぎりぎりまで開放されません。「ぎりぎりまで」ってのは、
「必要とされるまで」という意味で一見あたりまえで無害に見えますが、
ほかプログラムの起動時のコストやシステム全体のパフォーマンスから
見ると好ましくありません。


537 :仕様書無しさん:2001/06/15(金) 01:52
>>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()するかなんだから。
もちろんこれは、今の議題とはべつの議論だけどさ。

538 :仕様書無しさん:2001/06/15(金) 01:56
>>527
長すぎたか…

どっちにしろ、いまfjでやってるのは、互いのレトリカルな表現が気に入らないから
自分の気に入ってる表現に直せってことなんだよね。偏見入ってる意見かもしれんが。
ほとんどの事項で合意は成り立ってるんじゃないかな?

539 :仕様書無しさん:2001/06/15(金) 02:01
>>536
それって本当?開放されないってどのレベルで?
どういう仕組みになってるんだろ?>NTのメモリ管理
いや、本当にしらないので。

540 :仕様書無しさん:2001/06/15(金) 02:16
>>507
ペアだったら1対1だけど、対称とか、fjでは対応ということばも使ってたよね。
だからどれかなと。
それと、ペアにするのはどのスコープ内でなのだろう。

541 :仕様書無しさん:2001/06/15(金) 10:07
>>526
> freeしたら破綻するような実例をたった一つageればすむことなんじゃないの?
fjではスラッシングがageられていた

# fj読めよ

542 :仕様書無しさん:2001/06/15(金) 11:18
それってexit直前にfreeすると何か変わるの?
(変わるならNTって逝かれてる。)

543 :名無しさん:2001/06/15(金) 11:54
>>542
変わるのはmallocでなく、「なんちゃらalloc」という関数。
少なくとも新K&Rで掲載しているmallocのソースを見る限り
変わらないと判断するのが妥当。brkという関数に対になる
関数がないから。
”終了時にリークする関数がmallocという名前で存在し得る”
という前提が非現実的。


544 :仕様書無しさん:2001/06/15(金) 11:59
>>537
> (main()をモジュールとしてってのが最悪だが)。
同意。で、そこら辺のセンスの怪しさが箱氏の論全体の怪しさに繋がる。

545 :仕様書無しさん:2001/06/15(金) 12:17
>>512
> 組込のようなサイクリックプロセスでは
> リークを許すと上限は必ず無限大になる。

512 の組み込みはトランプの城のような安定性。

組み込みのようなプログラムでこそレイヤで「防壁」を
設けることが重要なんじゃないかって同スレで Kono 氏が言ってたよ〜
資源管理の防壁単位でリセットかませばリーク消し飛ぶじゃん。
「必ず」のわけないじゃん。

# やはり声を大にして言わなきゃならんな。fj 読めや。
# 読まない奴に限って free なのは
# 勉強しないプログラマ=free 派だとの傍証のような〜(煽り煽り)


546 :仕様書無しさん:2001/06/15(金) 12:44
> 大域空間って、グローバル変数のことだったんですね。
> てっきりヒープ(malloc()で取得できる空間)だと思ってました。
> #これからはそのように理解いたします。
だれかこいつに「逝ってよし」って言ってやれよ。
# だんだんウザイよりも哀れになってきた...


547 :仕様書無しさん:2001/06/15(金) 12:54
>>545
># 勉強しないプログラマ=free 派だとの傍証のような〜(煽り煽り)
設計できないプログラマ=free必要派じゃなかったっけ?(さらに煽り

548 :仕様書無しさん:2001/06/15(金) 13:11
>>546
ここ数日 fj.comp.lang.c 読んでいないけど、その発言って例の Sugihara ?
あの馬鹿なら言いそう。っていうか、あいつ完全に初心者だろ。C 言語歴 1 年
以内くらいの。藁

549 :仕様書無しさん:2001/06/15(金) 13:36
mallocとヒープが関係していることは学習したようですが?

550 :仕様書無しさん:2001/06/15(金) 13:50
>>549
でもグローバルという言葉の意味までは考えなかったらしい(藁
次は「えっ関数もグローバルなんですか」とか言い出すぜ、きっと。


551 :仕様書無しさん:2001/06/15(金) 14:05
>>546
おいらそれみてHAGESHIKUワラタよ。

どんなツッコミがくるのか今から楽しみ。


552 :仕様書無しさん:2001/06/15(金) 14:47
>>526
> つーかさー「mallocしたら必ずfree」を論破するには
> くだらん主張をを延々とやってないで
> freeしたら破綻するような実例をたった一つageればすむことなんじゃないの?

「free しなくても破綻しない実例」の間違いでは?

553 :仕様書無しさん:2001/06/15(金) 14:54
> 「free しなくても破綻しない実例」の間違いでは?

Compiler の構文解析木とか。


554 :仕様書無しさん:2001/06/15(金) 16:24
メモリリーク
「動的メモリ割り当てシステムにおいて、利用できないメモリ領域が生じること。そのような領域が徐々に増えていくこと。またその領域のこと。
メモリ割り当てシステムの管理下からメモリが漏れ出して、利用可能なメモリ領域が減ってしまうように見えるのでこの名がある。
(例)
・プログラム内におけるメモリリーク
そのプログラムで利用しておらず、将来再利用もできないメモリ領域が生じること。
・OSにおけるメモリリーク
どのプロセスも利用しておらず、将来プロセスに割り当てることもできないメモリ領域が生じること。」

555 :仕様書無しさん:2001/06/15(金) 17:36
>>552
「free しなくても破綻しない実例」なんか出して何か意味あんの?

んで、「Compiler の構文解析木」という例が出たけど、それで一体
なにが導き出せるんだ?

556 :仕様書無しさん:2001/06/15(金) 18:14
# 勉強しないプログラマ=free 派だとの傍証のような〜(煽り煽り)
>>めんどうだからフリー派でいいや

557 :仕様書無しさん:2001/06/15(金) 19:32
>>555
1 必要な free を省けば、当然問題を起こす。
2 不必要な free(書いてあっても問題は起こさない)は省いてもよい。
3 余計な free は、当然問題を起こす。
このうち3は、今の議論では問題外。

で、「mallocしたら必ずfreeしろ」ってのは、2の不必要な free も
省かずに書けって言ってるわけだから、「free しなくても破綻しない
実例」は反例になる。
「freeしたら破綻するような実例」こそ、この議論にはまるで関係ないと
おもわれ。

# もっとも、納得するかどうかは別問題で、そういう説明をされても「うちの
# 環境では…」と暴れだしたのが某箱氏。

558 :仕様書無しさん:2001/06/15(金) 19:41
はぁ?誰も「mallocしたら必ずfreeしろ」なんて主張してねーぞ。

つーか、今だにそんな先入観持ってた奴がいたのか。

559 :557:2001/06/15(金) 19:52
>>558
>はぁ?誰も「mallocしたら必ずfreeしろ」なんて主張してねーぞ。

ああ、そうか。
んじゃ

で、「mallocしたら必ずfree」ってのは、2の不必要な free も省かずに
書くって言ってるわけだから、「free しなくても破綻しない実例」は反例になる。

に修正。



560 :仕様書無しさん:2001/06/15(金) 20:43
>>557
でもそんな議論はとっくに終わっていて今は、
「free()したほうが、
(1) debugのために便利
(2) バグ(リーク)が減る
(3) あとでモジュール化するときに不便
だから、原則?free()したほうがコストが下がる。」
とかいう主張に、
「まぁ、そういうこともあるだろうけど、一般的には違うでしょ?」
とかやってるわけですよ。

561 :仕様書無しさん:2001/06/15(金) 20:46
そういえば
>(2) バグ(リーク)が減る
っていってたひとはどこに?

562 :仕様書無しさん:2001/06/15(金) 21:21
>>561
片岡モドキか? fj読み直してんじゃねーの?(藁

563 :仕様書無しさん:2001/06/15(金) 23:40
>>557 をー、裏を返せばそういう受け取り方もできるのカー、としばし感心
この人は論理学がすごく得意なのかヒネクレてるかのどっちかだろう(アヲリ)

もともとの fj の議論はまさに3も重要な論点だったのだよ。
「余計なfreeなどない!freeして問題が起きるのは設計が悪いからだ」
みたいなことを言ってた人もいたしね。だからfreeしたら破綻する例として、
コンパイラの構文木やスラッシングの話がfjで出たのさ。


564 :仕様書無しさん:2001/06/16(土) 03:21
>>557
省いても良いfreeを省いても当然問題は生じないのだが(w

free派は「そういうfreeも書いとくと、たまぁに良いことがあり、コストとベネフィットを平均するとプラスである」と主張していると思われ。

なので1つや2つ「良いことがない」例を挙げても反論にならないのでは。

565 :仕様書無しさん:2001/06/16(土) 05:16
free 派の心情が 564 が説明してるようなものだとして、
するとやっぱりそれは宗教なんじゃなかろーか。

たまぁに良い事がありってあたりがなんだか
カーゴ・カルトの信者みたいだよ。

566 :557:2001/06/16(土) 05:26
>>563
いや、別に揚げ足を取ってるつもりはなくて、ただ素直にそう思っただけっす。
根がヒネクレモノなんですかネ(^^;

>>564
御意。たしかにその通りですな。

ただし、納得するしないという点では、1つ2つ「freeしたら破綻するような実例」
出しても、「そういう例外はあるけど、原則は…」とやはり説得不能とおもわれ



567 :Sugihara(偽):2001/06/16(土) 05:39
ヒープソートって malloc 使うからそういう名前なんですよね?

568 :仕様書無しさん:2001/06/16(土) 06:26
Kono の言うことを無批判に受け入れる人もいるんだね。

569 :仕様書無しさん:2001/06/16(土) 06:41
気になったのですが、
最近のWindowsって解放忘れたメモリーも解放してくれるのですか?

今まで信用してなかったから 全部free してましたけど...。
JAVAと同じように OS側がメモリー解放をしっかりしてくれるって思うと
すこし気が楽に組めそうです。


570 :仕様書無しさん:2001/06/16(土) 07:13
>>568
まず568さんに「レイヤ作って防壁」への批判をお願い致します。
無批判に〜などとそしるのであれば可能なはず。

571 :仕様書無しさん:2001/06/16(土) 13:33
>>570
レイヤはすでにmallocで分かれているので必要ありません。

572 :仕様書無しさん:2001/06/16(土) 14:12
>>569
exitで解放できないならfreeでも解放できないはず、ってのがとっくにfjで出てる。
(ただしmalloc()でなく なんちゃらAlloc()みたいなのは別。)
fj読めや。

573 :仕様書無しさん:2001/06/16(土) 14:16
>>566
同意。いずれにせよ1つの反例で片付く問題ではない。
おいら的には「省いてよいfreeは省いてよいに決まってんじゃん!」で終わってるのだが。

574 :仕様書無しさん:2001/06/16(土) 14:46
>「省いてよいfreeは省いてよいに決まってんじゃん!」
これって金取ってる複数人プロジェクトでやってるの?

575 :574:2001/06/16(土) 14:56
ついでにどんな分野のアプリで何人月くらいの規模なの?

576 :仕様書無しさん:2001/06/16(土) 15:03
>>574-575
何で技術的な理由で満足できずに、規模とか金に拘るかな。技術的な
正否を自分で判断できないのか?

577 :574:2001/06/16(土) 15:16
>>576
よ〜するに、この手法は規模とか金とかに絡んだ分野での
実績がないって事?
単にこの手法の実績の有無しが聞きたいだけなんだけど。

実績のないぼ〜やには聞いてないよ。

578 :仕様書無しさん:2001/06/16(土) 16:19
>>577
仕事内容の詳細を、外に出せるとは限らないでしょうが。

実績の有り無しだけ言えば、私のところでは「有り」なんだが、それを聞い
てどうするよ? 実績があっても、腐った開発手法なんていくらでもある。
最後の拠り所は、技術的な正否だけでしょ。

> 実績のないぼ〜やには聞いてないよ。
現役の職業プログラマですが、何か?

579 :仕様書無しさん:2001/06/16(土) 16:56
現役の職業プログラマだって腐った奴はいくらでも居る。

580 :574:2001/06/16(土) 17:18
>仕事内容の詳細を、外に出せるとは限らないでしょうが。
詳細には興味ないよ。この手法の適用可能なおおまかな規模と分野を知りたいだけ。

>最後の拠り所は、技術的な正否だけでしょ。
そりゃ違うね。文法的仕様的にあっているかどうかと言うことと
まともな開発に耐えうるかどうかということは全く別次元の話だよ。

>実績の有り無しだけ言えば、
実績「だけ」を聞いてるわけではないよ。聞きたいのは以下の点。
・複数人で開発する場合にコンセンサスを得られるか?
・規模がある程度大きくなった場合破綻しないか?
・Bounds Checketのようなツールの動作を阻害しないか?

想像するに573,578の言う実績ってこんなものじゃない?
・開発人数:一人(メンテも自分でやる)
・規模:千行以下(良くて数千行以下)
・バグ検出ツールの併用:無し

581 :仕様書無しさん:2001/06/16(土) 17:36
そだね。
そもそも組込みとかだったら「省略可能なfree」が存在しないことの方が多い気がする。

582 :仕様書無しさん:2001/06/16(土) 17:44
つーか、C++のnew/deleteはセットにしないといけないし、
資源豊富な環境のCなら、GCでも使った方がよっぽどいいし、
タイト環境のCなら、malloc/freeという仕組み自体使うのを
考慮しなきゃいけない(独自のアロケータとか)。
 そんなわけで、この話は終わってると思うが。

583 :仕様書無しさん:2001/06/16(土) 18:18
>>580
> この手法の適用可能なおおまかな規模と分野を知りたいだけ。
それを判断するための材料は既にこのスレッドと fj の議論で出尽くし
てると思いますが、何が不足しているとお考えで?

584 :>583:2001/06/16(土) 18:27
>それを判断するための材料
だから判断「材料」を知りたいんじゃなくって実績が知りたいんだってば。
どうも妄想だけで議論が進んでるような気がするので。

585 :仕様書無しさん:2001/06/16(土) 19:39
省いてよいfreeを省くのに理由はいらない
省いてよいfreeを書くのには理由がいる

実績を挙げて説明すべきなのは書く側だと思われ

586 :仕様書無しさん:2001/06/16(土) 19:52
>>585
デムパ君?

long int i;
long i;

省いてよいintを省くのに理由はいらない
省いてよいintを書くのには理由がいる

と思うか?

587 :仕様書無しさん:2001/06/16(土) 20:49
>>584
> どうも妄想だけで議論が進んでるような気がするので。
気のせい。スレッド読み返しましょう。

588 :仕様書無しさん:2001/06/16(土) 21:41
>>587
気のせいなら>580に答えてよ。
実績のない妄想君じゃないんならさ。

589 :576=578:2001/06/16(土) 23:22
>>588
ウチでは実績があるって書いたじゃない。匿名掲示板で、詳細を伏せ
て書いたことに対して

「信用できない、どうせ数千行程度、一人で保守してる子供だましの
プログラム開発なんでしょ」

と返されたら、それ以上言うべきことは何もありませんな。あとは、ここ
のスレッド読み返してださい。書くべきことは、もう書いたから。

590 :仕様書無しさん:2001/06/17(日) 00:02
>>580
>・複数人で開発する場合にコンセンサスを得られるか?
これがfjとかでいわれてる、いわゆる「お寒い状況」ってやつですか?
でも現実はそんなもんかもね。だから宗教だって言われるんだろうけど。

>・規模がある程度大きくなった場合破綻しないか?
しないよ。

>・Bounds Checketのようなツールの動作を阻害しないか?
これがそんなに大事ならfree()してれば?
「チェックして大丈夫だった〜やった〜」とかいう気休めがそんなにほしいのかね?

とかかかれていたような気がす

591 :Bounds Checket?:2001/06/17(日) 00:15
Boudns Checkerってメモリ境界を越えたアクセスとかを検出するツールのことだから
この議論には関係ないんじゃ、と思ったら
http://www.numega.com/devcenter/bc.shtml
これのことなのね。なるほど。

592 :仕様書無しさん:2001/06/17(日) 00:57
もとの話題がfree-on-exitなのになんで「組み込み」とか「ずっと走るプログラム」とかdeleteとか言うやつがいるんだろ。fj全然読まずに脊髄反射してるのが一目瞭然。

規模? 何人のプロジェクトだろうと、アセンブラのシンボル表やコンパイラの構文木をexit前にいちいちfreeしてたら即クビでしょ。

593 :仕様書無しさん:2001/06/17(日) 02:15
省いて良いfreeなら省いて良いに決まってるだロー
「省いて良いfreeは省いちゃダメ」って見るからに矛盾じゃん(w
あったま腐ってんじゃないの?

594 :仕様書無しさん:2001/06/17(日) 02:27
>>593
「free必要派」は、「省いていいfreeなどない!(ただし例外アリ)」といいたいのではないかと。
その理由が>>580

>>592
>脊髄反射してるのが一目瞭然。
同意。特にdeleteを持ち出すやつは論外だね。

だいたい「組み込み」とか「ずっと走るプログラム」(終了しないプログラム)で
ちゃんとfreeしないといけないのは当然だろ(もちろん"例外"のmallocもあるよ)。
で、ちゃんとfreeするために独自のアロケータを作ったりGC使ったりしろって言われてんだろ?

595 :仕様書無しさん:2001/06/17(日) 02:59
>>580
> ・Bounds Checketのようなツールの動作を阻害しないか?
もちろん free() しないということは、その手のツールで「終了時に解放
されていないリソース一覧」を表示させると、そこに表示が出ることに
なる。じゃあ逆に、表示が出ないことにどれほどの意味がある?

この手のツールは、「リークがある」ことは指摘できても「リークがない」
ことは保証できない。だから開発時には、いろいろテストを用意して、
それぞれのテストで

 プログラマが予期したとおりにリソースが確保/解放されている

ことを確認していく。各テストはプログラム終了時に行うわけではな
いから、当然のことながら解放されていないリソースも存在する状
態で行われる。

ソフトウェアのテストをしたことがあるなら、プログラマが意図的にリ
ソースを解放しないことで

 「ツールの動作が阻害される」

はずがないことは明白なんだが。そんなツールは、あったとしても実
用にならないから。

596 :仕様書無しさん:2001/06/17(日) 03:27
>>595
exit-on-freeするやつらはきっとプログラム終了時のチェックしかしないんだよ

597 :仕様書無しさん:2001/06/17(日) 15:41
糞スレにつきage

598 :仕様書無しさん:2001/06/18(月) 02:24
fjに片岡再登場!

>自分が作るプログラムの外にあるものって何でしょうかね。
>OS? コンパイラ?
>
>ネットワーク越しの端末に「しばらくお待ちください」と表示したまま
>exit や異常終了するとお客様からファイヤーが来るとも来ないとも、
>確かに規格書には書いてありませんけどね。
>
>責任範囲って何? あんたらの仕事には存在しない??
>そりゃ尻拭いって場面は現実問題としてはありますけど、
>そんなの込みで主張されていますかね、本当に。

今度は最初からやけにテンション高い。
書いてることは相変わらずキティ外だが。
free-on-exitが是か非かの話が、いつのまにかexitが是か非かに化けてるし(w


599 :仕様書無しさん:2001/06/18(月) 12:39
> 片岡再登場!
K山と一瞬見間違った。

# G神も再登場したらあと半年は続きそうだ。


600 :仕様書無しさん:2001/06/18(月) 14:05
片岡か。こいつ確か fj の別のグループでスピード違反していると堂々と
語っていなかったっけ。んで周りにドキュソ扱いされていた。

そんなこと公の場で発言していい事じゃないよね。

601 :仕様書無しさん :2001/06/18(月) 20:22
G神はなぁ…。
まともに仕事を仕上げた事が無い。
能書き垂れまくって仕事をもらい、
言い訳垂れまくってほっぽり出す。
その繰り返し。
もう誰も信用する人がいなくなったから米国へ移住した。

602 :仕様書無しさん:2001/06/18(月) 22:05
>>601
例え本当でも、そゆこと書くのは良くないと思うぞ。

603 :祝 相互リンク(藁:2001/06/19(火) 12:29
こんにちは、鶴田(SYN)です。

各自の主張はもう十分に理解されていると思います。お互い譲れな
い部分はあると思いますが、これ以上続けてもネタになるだけで、
双方に何のメリットもない気がしてきました。

まだ、フォローしたい人もいるだろうし、私もしてしまうかもしれ
ませんが、これは見ておいたほうが良いと思います(藁)。

プログラマー@2ch掲示板
「始まった!malloc and free - fj.comp.lang.c」

http://mentai.2ch.net/test/read.cgi?bbs=prog&key=981051921


604 :Sugihara(偽):2001/06/19(火) 14:23
面白かったです。

605 :妻ら中田です:2001/06/19(火) 14:29
>>604
消防の読後感想文レベルだな(w

606 :ミーハー:2001/06/19(火) 14:41
すぎうらさん、箱さん、海亀さん、文平さんで
オールスター戦をキボンヌ。


607 :仕様書無しさん:2001/06/19(火) 14:49
>>603-604
何をいまさら・・・

608 :仕様書無しさん:2001/06/19(火) 15:08
文平さんかー、なんか記憶の底に澱もののように沈んでいた名前だ。
なにしたひとかどうしても思いだせん。



609 :仕様書無しさん:2001/06/19(火) 15:13
>>608
http://mentai.2ch.net/isp/kako/950/950464541.html

610 :仕様書無しさん:2001/06/19(火) 16:18
>>609
さんくす。おかげさまで思い出すことができました。

いやー一年なんてはやいものだね。

611 :仕様書無しさん:2001/06/19(火) 23:26
おかげさまで活発な議論もようやく収束しました。
みなさんお疲れさまでした。

せっかくなので議論の結果をまとめておきます。

・malloc, freeは「必ず」対で使用する。
・(ヒープの断片化などで)malloc, freeを直接使用するのが好ましくない場合は
 自前のヒープ管理ルーチンでを導入する。
・GCのあるJavaの導入を検討する。

例外
以下のケースではfreeしない事を検討してもよいでしょう
・社内のコンセンサスが不要なくらい孤独な場合。
・"free(p);"を省くことで全体のタイプ効率の向上が望める程度にソースが短い場合。
・今後自分でメンテナンスしないことがはっきりしている場合。

Cを勉強中の方(特に学生さん)は
この議論の流れと結論をじっくり吟味してください。
そしてfree不要派の反面教師ぶりをしっかりと目に焼き付けてください。
みなさんが今後ソフトウェア開発業界で活躍する上で、
このスレッドで得られた知見が貴重な糧となることでしょう。

葬送

612 :仕様書無しさん:2001/06/19(火) 23:35
なんかさ2chの議論で「必要なのにsageしない厨房」が増えたような気がしない?
>>1-999とかもわかったようなこと書いてるけど、微妙にはずしてるし。

613 :仕様書無しさん:2001/06/19(火) 23:45
>>611
つまらんネタ。
「free不要派」ってとこだけちょっとワラタ。なんだよそれ。


614 :仕様書無しさん:2001/06/20(水) 00:05
さっそく一匹釣れました(藁

615 :仕様書無しさん:2001/06/20(水) 00:06
>>611 >>614
ネタとしては及第点だが(優/良/可/不可で可)、sage てないのが
減点。精進して下さい。

616 :仕様書無しさん:2001/06/20(水) 08:47
おかげさまで活発な議論もようやく収束しました。
みなさんお疲れさまでした。

せっかくなので議論の結果をまとめておきます。

・チンコ, マンコは「必ず」対で使用する。
・(包茎の皮の断片化などで)チンコ, マンコを直接使用するのが好ましくない場合は
 コンドームを導入する。
・経口避妊薬(ピル)の導入を検討する。

例外
以下のケースでは避妊しない事を検討してもよいでしょう
・社内で孤独に陥った末の強姦の場合。
・避妊を省いても、全然膣に届かない程にチンコが短い場合。
・今後自分で子育てしないことがはっきりしている場合。

Cを勉強中の方(セクースの意味だゴルァー)は
この議論の流れと結論をじっくり吟味してください。
そして避妊不要派の右反りチンコぶりをしっかりと目に焼き付けてください。
みなさんが今後セクース業界で活躍する上で、
このスレッドで得られたエロ知見が貴重な種(精子のことだゴルァー)となることでしょう。

イッテヨシ

617 :仕様書無しさん:2001/06/20(水) 09:08
fjの連中ってどうしてこんな
基地外ばっかなんだろ

618 :仕様書無しさん:2001/06/20(水) 10:27
  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ( ´∀`) <  オマエモナー
 (    )  \____________
 | | |
 (__)_)

619 :仕様書無しさん:2001/06/20(水) 13:57
形式論理もよう把握できんヴォケがあがいても意味ねーわ

620 :仕様書無しさん:2001/06/20(水) 14:32
>>617-618
おお!すげえ久しぶりに典型的な2ちゃんねるのレスを見たよ。

621 :いいじゃないか:2001/06/21(木) 11:16
とりあえずこのスレ上げます( ´∀`)

622 :仕様書無しさん:2001/06/21(木) 17:09
なんか終わったようだね…。

623 :仕様書無しさん:2001/06/22(金) 00:08
>さらに単純な命題に分析します.
>
>P1 :「free()絶対する派」はコストバランスを全く考えていない.
>P2 :「原則free()」を唱えている人はコストバランスを全く考えていない.
>Q1 : 「free()絶対する派」はコストバランスを考えていても原理原則より
> 下に見ている.
>Q2 : 「原則free()」を唱えている人はコストバランスを考えていても原理
> 原則より下に見ている.
>
>上と同様に(今度は「述語の共通化」により)P は「P1 or P2」と同じ意味で,
>Q は 「Q1 or Q2」と同じ意味になります.
誰か命題のorの取り方教えてください。

624 :仕様書無しさん:2001/06/22(金) 00:20
>>622
また一年後ぐらいに再開する、に一票。

625 :仕様書無しさん:2001/06/22(金) 00:24
>>624
このスレがなかなか終わらないに一票かな。

626 :仕様書無しさん:2001/06/22(金) 00:39
忘れた頃にmalloc&free

627 :仕様書無しさん:2001/06/22(金) 06:52
#define memalloc(x) malloc(x)
#define memfree(x) free(x)
にすればmallocもfreeも使わなくてヨシ。
っていうか皮被りじゃない俺逝ってよしなら逝ってくる。

628 :仕様書無しさん:2001/06/22(金) 09:40
#define freeallonexit()
良ければ使ってください。

629 :仕様書無しさん:2001/06/25(月) 02:38
片岡いまだ死なず

>> したがって、 プロセス終了時にOSが(プロセス自身の解放によって)
>> 処理される事を期待する以外にないことを意味します。
>
>同じことですね。
>「そのOS」がプロセスを正常に解体できること *だけ* は
>Cで書く限り処理系に依存せず保証されているとお考えですか。
>
>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。
>
>どこまでが自分の落ち度かを切り分ける能力は
>アマとプロの違いの1つとも思えます。

はぁ〜あ、いまさら何いってんだか。free-on-exitしてもしなくても関係ないじゃん。
free-on-exitしてもしなくてもOSがダメならリークするし、まともなOSならリークしない。
こいつもSugiharaと同じレベルだな。態度がでかいぶんタチが悪い。

630 :仕様書無しさん:2001/06/25(月) 13:19
> どこまでが自分の落ち度かを切り分ける能力は
> アマとプロの違いの1つとも思えます。

assert()を実行したときに条件が充たされていないとプログラムは
終了しますが、OSやライブラリによるメモリ領域の解放が行われな
いとすると、そのときまでにfree()されていなかったメモリブロッ
クの領域はリークすることになります。
こういう場合は

(1) assert()を使ったのがプログラマの落度である。
(2) assert()が実行される前にすべてのメモリブロックをfree()す
るようにしておかなかったことがプログラマの落度である。

のどちらになるのでしょうか。

--

assert を使っているぐらいなら恐らくテスト段階だと思われるので、
別にメモリリークがあってもいいような気がするのは自分だけ?

それとも assert って release 版にも入っているもんなのかな?

631 :仕様書無しさん:2001/06/25(月) 14:43
いまだにゴチャゴチャ言ってるヤツは、下落したメモリすら買えない貧乏人。
と煽ってみる。

632 :仕様書無しさん:2001/06/25(月) 20:00
release版でassert()を外す...
そゆのは「陸上で救命胴衣を着て練習し、沖に出るときに救命胴衣を外す
ようなもの」と言ったエライ人がいるね。

633 :仕様書無しさん:2001/06/26(火) 00:34
>>630
>別にメモリリークがあってもいいような気がするのは自分だけ?
assert()までにfree()されていないメモリブロックって
かなりでかいだろうから、そのうち仮想メモリまで使いきっちゃうと
思うぞ。

634 :仕様書無しさん:2001/06/26(火) 00:51
>>632
assert ってデバッグ時以外にも使うものなのか…。
おいら知らなかったよ…。

635 :仕様書無しさん:2001/06/26(火) 11:55
> 「そのOS」がプロセスを正常に解体できること *だけ* は
> Cで書く限り処理系に依存せず保証されているとお考えですか。

この部分を

コンパイラがwhile文を正しく扱えることはCで書く限り処理系に依存せずに
保証されているとお考えですか。

とかえてみる。

636 :仕様書無しさん:2001/06/26(火) 19:47
>>635
>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。

これは

>「そのOS」がプロセスを正常に解体できるかどうかに係わらず自分は
>「そのOS」がプロセスを正常に解体できることを当てにしないプログ
>ラムを書くべきと私は考えますがね。

とゆうことだから、635のように換えると

>コンパイラがwhileを正しく扱えるかどうかに係わらず自分はコンパ
>イラがwhileを正しく扱えることを当てにしないプログラムを書くべ
>きだと私は考えますがね。

となるね。

637 :仕様書無しさん:2001/06/27(水) 23:48
>自分が書くプログラムの外にあるものが正しいかどうかに係わらず
>自分は落ち度のないプログラムを書くべきと私は考えますがね。
を、

インポートしたDLLが壊れているかどうかに関わらず
自分はそのDLLが正しく使えることを当てにしない
プログラムを書くべきだと私は考えますがね。

とも変えてみる。

638 :仕様書無しさん:2001/06/28(木) 07:07
「外にあるものが正しいかどうかに係わらず」
なんじゃこれ。オカルトプログラマか。

薬効成分がなくなっても効き続ける薬なんて
ネタがオカルトサイエンスにあるけど、
それと似たようなものだろうか。

コンピュータの電源が落ちていても
動くべきプログラムとか。(゚д゚;;;コワヒー

639 :仕様書無しさん:2001/06/28(木) 07:52
↑つ,つまらなすぎ・・・・・

640 :仕様書無しさん:2001/06/28(木) 09:49
時として、バグのある環境で動かすためにアプリ側で対処する必要があるのは確かなのだが、
バグのある環境を事前に想定してプログラムを組むというのはやはり無駄な労力だと思われ。

641 :仕様書無しさん:2001/06/28(木) 14:16
>>639
悪かった。連日寝不足なんだよ。

またも片岡が前回の結論を全く参照せずループ状態に陥ってる
ところをみると、freeをわめく連中のやってるのは議論ではなく
プロパガンダって事だね。

642 :仕様書無しさん:2001/06/29(金) 07:11
世の中暇人が多いんですね。<fj

643 :仕様書無しさん:2001/07/04(水) 10:50
箱登場。

644 :仕様書無しさん:2001/07/04(水) 12:49
週に一回の発症か。

645 :仕様書無しさん:2001/07/04(水) 23:20
>> “Subject: Re: free-on-exit and its practical value”をお忘れで
>> すか。
> malloc() ライブラリに対する私のインターフェースには、プログラム終了時など
>と言う条件は入っていないと言っているのですけど、理解できませんか ?
ワラタ。

646 :しようしょなしさん:2001/07/05(木) 06:16
箱氏、なんだかだ言って結合が密になってるじゃん。
それで疎になると称するのは技術者としてどうよ?

647 :仕様書無しさん:2001/07/06(金) 11:01
あの議論に参加している人ほとんどが技術者として失格。

648 :仕様書無しさん:2001/07/06(金) 11:17
理論こねくり回してる奴って二流多いよな。
コーディング規約守れとか、姑かっつーの。
プログラマならコードで語れ。

649 :仕様書無しさん:2001/07/07(土) 03:24
>>647-648
なんかまるでGonzoな人たちみたいに見えるだよ(藁
http://namazu.org/~satoru/misc/gonzo.html

650 :しようしょなしさん:2001/07/07(土) 06:53
マッチョと同義でしたっけ? <ゴンゾ
ページに書いてある例は「理論や大局観の欠落したスタンス」みたいですが。
「ある意味、典型的なCプログラマ」なんて揶揄もあったな。

で、「とりあえずコード書いとけ!」も「とりあえず free 置いとけ!」も同じと。

651 :仕様書無しさん:2001/07/08(日) 01:34
>> よって、まともな環境では、mallocしたメモリを
>> freeしないで終了しても差し支えない。
>
>規格制定以前の、それこそ互換性クソっ食らえで作られた
>既存のコードが擁護されているだけです。
>
>今日でも、互換性クソっ食らえで書くコードになら
>よい考えかも知れません。
>
># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか?

652 :仕様書無しさん:2001/07/08(日) 01:36
片岡:

>> よって、まともな環境では、mallocしたメモリを
>> freeしないで終了しても差し支えない。
>
>規格制定以前の、それこそ互換性クソっ食らえで作られた
>既存のコードが擁護されているだけです。
>
>今日でも、互換性クソっ食らえで書くコードになら
>よい考えかも知れません。
>
># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか?

誰かこのKitty飼いの言ってること通訳して。
互換性を前提にするならstaticがゼロクリアされてると
仮定していいんじゃないの?

653 :仕様書無しさん:2001/07/08(日) 02:26
片岡は、
・freeしてからexitしてもメモリリークが起きることを仮定する
だけじゃなくて
・static領域はゼロクリアされていないことを仮定する
ノカー。

そこまで疑うなら「代入文で値が書き変わる」とか「配列が宣言した大きさど
おり確保される」ことも疑ってかかるに違いない。

まともなプログラム書けんじゃないか。

654 :仕様書無しさん:2001/07/08(日) 04:41
ホントに基地害だなこの片岡って
しかも、何度叩かれても平然と同じこと繰り返す粘着ぶり
こわー

655 :仕様書無しさん:2001/07/09(月) 03:39
>> exit前のfreeは書かなければならないものなのか、
>> それとも書かなくても良いものなのか
>>
>> という疑問に、どうやって解答すれば良いのですか?
>こう答えればよいでしょう。
>
>なぜ exit が出てくるのか?
>あなたは、互いに関係のない話を分離する訓練をするべきだ。
>具体例を1つ、安直に exit するな。
だれかこの基地害をなんとかしてクレー。

656 :仕様書無しさん:2001/07/09(月) 09:39
箱氏はどうなんだろう。
こいつもほとぼりさめたらまた出てくるんか。

>> 2. 制約ができるはずなのにレイヤー間の結合が疎になるという謎の主張.
> 制約と結合って関係ないと思います。

こんな酷い無知を晒して議論続行なんて普通は出来んよな。
結合の意味知らずに疎になるも密になるもねーだろうに。

657 :仕様書無しさん:2001/07/09(月) 10:23
>>656
箱氏は週に一度おこる発作だと思うけど。

658 :(・∀・)イイ!!スレッドあげ:2001/07/09(月) 16:54
箱の場合、日本語に対して普通の日本人が理解している意味としばしば食い違って
解釈しているのが問題なんだろう。原則とか密と疎の意味とかね。だから議論が
ここまでかみ合わない。

Sugihara は単に経験が足りないだけ。いわゆる素人。だからよく意味もわからず
にこの議論に首を突っ込んでいるのだろうなぁ。

片岡は本物の既知街。上の両者なんか全然問題にならないよ。こいつは放っておい
た方がいい…。特にこれ、

># ひょっとして、static がゼロクリアされるなんて
># 奇麗事を本気で信じているクチですか?

やばすぎだろ。断言するが、こいつ絶対まともなプログラムを組めない。

659 :仕様書無しさん:2001/07/09(月) 17:17
あげ荒らし逝ってよし

660 :仕様書無しさん:2001/07/09(月) 23:50
片岡(<9ia4pk$ilf$2@news01be.so-net.ne.jp>)
>そう、議論する場です。
>3B3E9A91.A8AE46FB@ffc.co.jp で、あなたがしたことは
>ハッタリかまして人を愚弄することだけであり、
>何ら「議論」にあたる内容が含まれていませんでした。

Kumano Akio(<3B3E9A91.A8AE46FB@ffc.co.jp>)
>> そんなはずはない、ことが起きているのがアサーション・エラーです。
>
>この一文に限っては同意できます。
は議論に関係ないらしい。
ちゅうか、片岡自分の発言に酔ってるだろ。
誰か片岡にここ見せてやれ……いや、基地外に見せても無駄か(藁

661 :(・∀・)イイ!!スレッドあげ:2001/07/10(火) 12:38
片岡ってどこで働いているんだろ。仕事で奴と関わりたくないから
情報きぼん。

662 :仕様書無しさん:2001/07/14(土) 19:34
箱発症

663 :仕様書無しさん:2001/07/14(土) 21:02
>>662
かなり重症の模様。

664 :仕様書無しさん:2001/07/16(月) 12:42
〜〜
> というか、main側の処理状況って確認できるんですか?

きれい汚いは別として、やればできますよ。
例えばグローバル変数でフラグを立てるとか...
〜〜

かたおかきゅん、スゴイ!スゴイヨ!
main との結合が弱くなるプログラムと言っておいて
グローバル変数を参照するのカ〜。

665 :仕様書無しさん:2001/07/16(月) 19:51
>>664
片岡はもっとすごいことを言っている。

> 「不要」かどうか判定するためには、
> プロセスが解体中または解体されようとしていることを
> 検出できることが必要です。
>
> つまり、free しようとしているモジュールから
> main 側の処理状況を確認する必要があるのです。

プロセスが解体中であることをそのプロセスで実行されている
プログラムで検出するには、プログラムが実行中にもかかわら
ずプロセスが解体されてしまう環境でなければならない。

ふつうの人なら、プロセスを解体する前にそのプロセスで実行
中のプログラムを停止させると考えるんだが、片岡はそう考え
ない。

ふつうじゃないから。

666 :仕様書無しさん:2001/07/16(月) 23:33
片岡(<9it3ib$a2p$4@news01bb.so-net.ne.jp>):
> > 終了前のfreeを省くと問題(メモリリーク等)が起こるのか、
> > それとも、省いても問題は起こらないのか
> >
> > という疑問に、どうやって解答すれば良いのですか?
>
>exit を終了と言い換えただけ。答えは同じです。
ってことは……

なぜ 終了 が出てくるのか?
あなたは、互いに関係のない話を分離する訓練をするべきだ。
具体例を1つ、安直に 終了 するな。

って答えろってこと? わけわからん。

667 :(・∀・)イイ!!スレッドあげ:2001/07/17(火) 13:01
>>666
うわ〜。全然答えになっていないですね。片岡は正真正銘の既知だな。

668 :仕様書無しさん:2001/07/17(火) 22:42
お互い、相手の言い回しに反射的に答えてるだけじゃ収束しようがないね。
free派はそういう泥沼化を目指すしかないんだろうが…

669 :仕様書無しさん:2001/07/18(水) 00:36
片岡:
>>>なぜ exit が出てくるのか?
>>>あなたは、互いに関係のない話を分離する訓練をするべきだ。
>>>具体例を1つ、安直に exit するな。
>> この記事、わけわかんないです。
>ここまではいいですが、

片岡、自分が既知害だということを認める。(藁

670 :結論:2001/08/08(水) 14:25
malloc したら必ず free しなければならない。一切の例外は認めない。

671 :仕様書無しさん:2001/08/08(水) 15:09
終了したスレに煽りはやめれ

672 :仕様書無しさん:2001/08/08(水) 19:36
この嵐の後すっかり寂しくなっちゃったね。> fj.comp.lang.c

673 :仕様書無しさん:2001/08/08(水) 20:10
誰か fj.comp.lang.c にまた爆弾を投げ込んでくれ。最近 fj.comp.lang.c
だけじゃなく、fj.comp.lang 自体がつまらない。

674 :仕様書無しさん:2001/08/08(水) 20:17
>>670
なんであげるんだよ。

675 :仕様書無しさん:2001/08/08(水) 20:25
>>674
上げ荒らしだから。(w

676 :仕様書無しさん:2001/08/08(水) 21:13
comp.japan (w

677 :仕様書無しさん:2001/08/09(木) 11:52
亀と同じく箱も人工無能であるという説に一票。

678 :仕様書無しさん:2001/08/09(木) 14:04
期待に応えて箱登場!マジかよ(w

679 :678:2001/08/09(木) 14:06
おまけに亀同様の時間差攻撃を身につけている様だぞ。

680 :名無しさん:2001/08/09(木) 14:10
_こうやって
先頭の空白にアンダーバーをつけるのがコツなんだよ>>箱さま

681 :仕様書無しさん:2001/08/09(木) 14:29
これでとどめをさしたね。

682 :仕様書無しさん:2001/08/09(木) 15:28
#返信への返信には約90日かかるだろう。

683 :仕様書無しさん:2001/08/10(金) 12:05
>>670

あるマンガ雑誌の今週号にこんなのがあった。

花壇の花には毎日水をやらなければならない。
雨がどれほど降っていようと関係ない。
例外は一切認めない。

684 :仕様書無しさん:2001/08/10(金) 14:28
>>680 >>682
ワラタ

>>683
なんというか…。教条的ですなぁ。花に水をやりすぎると枯れるんだよ。

685 :仕様書無しさん:2001/08/10(金) 19:30
雨がたくさん降っているときに花に水をやることに価値はないだろ
うという話をしているのに、私は毎日かかさず水をやるだけだ、雨
が降っているかいないかは関係ないと言いだすのが箱氏。
自分一人で勝手にやっているだけならいいようなもんだけど、他の
人も原則としてそうするべきだと言いだすのが箱氏。

686 :仕様書無しさん:2001/08/16(木) 20:11
箱より片岡をどうにかしてくれ。

687 :仕様書無しさん:2001/08/19(日) 07:17
まだどこかで暴れてますか?<片岡氏

688 :仕様書無しさん:2001/08/19(日) 23:21
今のところは沈黙しているようです。 < 片岡

689 :仕様書無しさん:01/09/04 14:09 ID:owRDFfk.
良スレにつき、定期sage

690 :545:01/09/09 21:00
ネタ枯れにつき(まあ当然だが)スレ読み返す。
フォロー忘れてたんで書いときますわ。

>>545 なんだけど、

?:malloc-free がない環境では
?:例えば組み込み環境など
Kono氏:むしろそういった環境でこそ防壁が必要

という流れがあったのを批判的な読みとして
「それこそ malloc-free を使えばいいじゃんか」などと
言い出す人(>>571)はやっぱり元記事読んでないんでは?

私も fj.sci.physics あたりの Kono 氏投稿を読んでるから
責めたくなる気持ちはわかるが、批判なら元の文脈から外れた
字面だけで責めるのはアウト。

691 :仕様書無しさん:01/09/14 20:54
ageとくか

692 :仕様書無しさん:01/09/15 01:57
ageんなよ!

693 :仕様書無しさん:01/09/17 17:04
そうだよ、ageんなよ!

694 :仕様書無しさん:01/10/03 18:16
憂慮薄れだ上げるぞ

249 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)