スレッド 「Malloc and Free」 が読めない

[Shin-ichi TSURUTA]

岡久さん、こんにちは、鶴田(SYN)です。

oka...@cs.ehime-u.ac.jp wrote:
> 岡久です。
>
> もう撤退すべきかもしれないな。

うーむ。私の方でも、このスレッドが続いていて一時撤退していた
のですが、どうしてこんなに続くのでしょうかねぇ。

> ところで、電子のお針箱さんは誰に反論してるのだろう... その人も
> 存在しないのかもしれないな。

私も、これがわからないんです。電子のお針箱さんは別に間違った
事を言っているわけではないと思うのですが、同意が得られている
と思われるにもかかわらず、反論という形態でスレッドが続くのは、
元の「Malloc and Free」の時から何も変わっていないんですね。

岡久さんもそうだと思うのですが、私は「善し悪し」について議論
しているわけなんです。どうあるべきかという「べき論」ですね。
それに対して、電子のお針箱さんはどういう現実があるかを述べら
れているのですが、そんなことは自明なんですね。

そういう現実があるからこそ、「善し悪し」を議論しているのであっ
て、そういう現実がなければ、そもそも「善し悪し」を議論する意
味がないはずなんです。問題は電子のお針箱さんが、既に分かって
いる現実を、「善し悪し」に対する反論と言う形で述べられている
事なんですね。意図的かどうかはわかりませんが、電子のお針箱さ
んが、開き直って悪を是としていると思われかねないことをわざわ
ざそれを述べられる理由はまったくわからないです。

# 殺人が起る。
# 殺人は良くないよねという議論が起る。
# でも、殺人は起きるよね。という、反論にならない反論が来る。
## そんなもの肯定してどうするんでしょうかね・・・。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> 望ましい状況になるとは言っていません。事実として、そう言う状況が存在すると
> 言っているだけです。望ましくないからと言って、そう言う状況がなくなるわけでは
> ないじゃないですから。
____________________________________________________________
Name : Shin-ichi TSURUTA 鶴田 真一 (as SYN)
E-mail : syn...@pop21.odn.ne.jp
URL : http://www1.odn.ne.jp/synsyr/

[Hiroyuki Minesita]

From article <8i6agu$5g2$1...@nwms2.odn.ne.jp>
by Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp>

> # 殺人が起る。
> # 殺人は良くないよねという議論が起る。
> # でも、殺人は起きるよね。という、反論にならない反論が来る。
> ## そんなもの肯定してどうするんでしょうかね・・・。

　なんか変な譬えになってませんか？
　私の印象だと……

　「全部を知る必要は無いよね？」
　「無知は罪でしょ？」
　「だって、必要のある事だけ知っていれば事足りるでしょ？」
　「だから、無知は罪なんだってば」
　「別に無知だからって罪じゃないでしょうに」
　「あんた知ってて言ってるね？」
　「そりゃ知ってなきゃ言えないよね」
　「だったらあんたは無知じゃないんでしょ？」
　「何時、俺の事だって言ったの？」
　「あんた自分の事を言ったんでしょ？」
　「俺に限った話をしてるんじゃないって」
　「じゃ、なんの話してるの？」

って、感じの流れになっているんですけど……

---
---------------------- 〃
　　　　　　　　　　　ヾ＜・)
峯下博幸　　　　　　　 （ ~彡
---------------------- κκ

[Shin-ichi TSURUTA]

峯下さん、こんにちは、鶴田(SYN)です。

mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> > # 殺人が起る。
> > # 殺人は良くないよねという議論が起る。
> > # でも、殺人は起きるよね。という、反論にならない反論が来る。
> > ## そんなもの肯定してどうするんでしょうかね・・・。
>
> 　なんか変な譬えになってませんか？

うーむ、ちょっとまずかったか。私の方のスレッドと合わせて、

ある現実がある。
「その現実は避けるべきである」
「でも、現実には、そういうことがある」
「その現実は避けるべきである」
「でも、現実には、そういうことがある」
・・・以下無限ループ。

と言う状態に陥っているとしか思えないんです。

> 　私の印象だと……
>
> 　「全部を知る必要は無いよね？」
> 　「無知は罪でしょ？」
> 　「だって、必要のある事だけ知っていれば事足りるでしょ？」
> 　「だから、無知は罪なんだってば」
> 　「別に無知だからって罪じゃないでしょうに」
> 　「あんた知ってて言ってるね？」
> 　「そりゃ知ってなきゃ言えないよね」
> 　「だったらあんたは無知じゃないんでしょ？」
> 　「何時、俺の事だって言ったの？」
> 　「あんた自分の事を言ったんでしょ？」
> 　「俺に限った話をしてるんじゃないって」
> 　「じゃ、なんの話してるの？」
>
> って、感じの流れになっているんですけど……

良くまとまってますね。(^^;

[Nakamura Akifumi]

中村っす。ごみ。

fj.comp.lang.c,fj.comp.lang.c++ の <8i6n8g$nm8$1...@sunny.njk.co.jp> の
記事において 2000年06月14日(水) 01時30分56秒頃、
Hiroyuki Minesitaさんは書きました。

>　「全部を知る必要は無いよね？」
>　「無知は罪でしょ？」
>　「だって、必要のある事だけ知っていれば事足りるでしょ？」

結局、なにが必要(知るべき)か「を」知ることが必要なんでしょうね。
わーい。メタだメタだ。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8i6oqf$25j$1...@nwms2.odn.ne.jp> の
記事において 2000年06月14日(水) 10時57分11秒頃、
Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp>さんは書きました。

>ある現実がある。
>「その現実は避けるべきである」
>「でも、現実には、そういうことがある」
>「その現実は避けるべきである」
>「でも、現実には、そういうことがある」
>・・・以下無限ループ。
>
>と言う状態に陥っているとしか思えないんです。

それってループなんですかね。再帰だったりして(ぉ

いやその、上記引用の2..3行目と4..5行目の、self(笑)が
別物なのか同じものなのか、どっちかなーと思いまして。

＃ま、今回は、どっちでもいいですけど(笑)

[Narita Takaoki]

成田です。

Hiroyuki Minesita <mine...@rd.njk.co.jp> wrote in message news:8i6n8g$nm8$1...@sunny.njk.co.jp...

> 　「全部を知る必要は無いよね？」
> 　「無知は罪でしょ？」
> 　「だって、必要のある事だけ知っていれば事足りるでしょ？」
> 　「だから、無知は罪なんだってば」
> 　「別に無知だからって罪じゃないでしょうに」

:

ちょっと違うのですが、ここら辺の議論を読んでいると、アラン・
クーパー氏の「コンピュータは、むずかしすぎて使えない！」の
中の、プログラマに関する言及の部分を思い出していしまいま
す。(^^;;;

--
Narita Takaoki @A.I.SOFT,INC.
『未知の謎が私をまっている、まだまだ死ねない』

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
news:8i6agu$5g2$1...@nwms2.odn.ne.jp...

> # 殺人が起る。
> # 殺人は良くないよねという議論が起る。
> # でも、殺人は起きるよね。という、反論にならない反論が来る。
> ## そんなもの肯定してどうするんでしょうかね・・・。

人が死ぬと言うことについて議論している時に...

「殺人によって死ぬ人もいるよね。」
「殺人は良くないから考えるな。」

と言われているように感じているのですが...。

# 殺人で死ぬ人の割合は少ないから考えなくても良いというのならわかります
# が...。

# 「峯下博幸」さんの様に正しく解釈されている方がいるのでちょっとは安心した
# のですが、書き方が悪いのかなぁ...。

--
--------------
電子のお針箱
ue...@di.mbn.or.jp
(From: ヘッダーはスパム対策のため -nospam を付加しています。)
--------------

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <8i6n8g$nm8$1...@sunny.njk.co.jp> ,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes
>　「全部を知る必要は無いよね？」
>　「だって、必要のある事だけ知っていれば事足りるでしょ？」

この二つって両立しないと僕は感じますね。というか、両方信じているなら、
必要のある事を、全部知る必要はない
っていうループを廻すと、必要なところがどんどん減っていく...

あの箱氏の主張って、結局、いい加減にプログラムしていいって以外に
解釈しようがないような...

やっぱり、
「必要な知識は、ちゃんと身に付ける」
だよね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> news:8i6agu$5g2$1...@nwms2.odn.ne.jp...
>
> > # 殺人が起る。
> > # 殺人は良くないよねという議論が起る。
> > # でも、殺人は起きるよね。という、反論にならない反論が来る。
> > ## そんなもの肯定してどうするんでしょうかね・・・。
>
> 人が死ぬと言うことについて議論している時に...
>
> 「殺人によって死ぬ人もいるよね。」
> 「殺人は良くないから考えるな。」
>
> と言われているように感じているのですが...。

例が悪かったのは、申し訳ないですが、これは逆ですね。良くない
から「考えろ」「気をつけよう」と申し上げているのですよ。
# まぁ、例が悪いから、この部分に議論しても意味が無いが。

> # 「峯下博幸」さんの様に正しく解釈されている方がいるのでちょっとは安心した
> # のですが、書き方が悪いのかなぁ...。

そうですね。私もそう思っていましたし。適切なフォローがあって
助かりました。

結局、これにつきるんですね。

mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> 　「じゃ、なんの話してるの？」

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> 望ましい状況になるとは言っていません。事実として、そう言う状況が存在すると
> 言っているだけです。望ましくないからと言って、そう言う状況がなくなるわけでは
> ないじゃないですから。

synsyr <syn...@pop21.odn.ne.jp> wrote:
> ありえるかどうかなど、議論の余地はないです。なぜならば、この
> 問題の元の発言がこれに該当してます。
> *あり得る*など、情報量０ですよ。

oka...@cs.ehime-u.ac.jp wrote:
> だから言ったのです。いったい何に反論しているのでしょう?
> 電子のお針箱さんは現実を告白しているだけで、何かの価値判
> 断をしたいわけではないのでしょう? 使わない方がよいという
> (* だけ *)のアドバイスは盲信しない方がよいことには賛成し
> ていただけるのですよね? 私は寒い現実の存在は認めるし無視

oka...@cs.ehime-u.ac.jp wrote:
> ここに、電子お針箱さんの矛盾が集約されています。反論していると言っ
> ておきながら、実際には事実を告白しているだけと言う。それが反論になら
> ないことがお分かりにならないのでしょうか? 電子のお針箱さんは事実だけ
> 告白してさっさと引っ込むべきだったのに、執拗に理由のよく分からない反
> 論を続けているわけです。
>
> もう少し、分かりやすく言い替えましょう。電子のお針箱さんは、この反
> 論だか事実の告白だかを通じて何を主張したいのでしょう? 特に無いのなら
> 反論するのは変な行為です。

oka...@cs.ehime-u.ac.jp wrote:
> ところで、電子のお針箱さんは誰に反論してるのだろう... その人も
> 存在しないのかもしれないな。

synsyr <syn...@pop21.odn.ne.jp> wrote:
> そういう現実があるからこそ、「善し悪し」を議論しているのであっ
> て、そういう現実がなければ、そもそも「善し悪し」を議論する意
> 味がないはずなんです。問題は電子のお針箱さんが、既に分かって
> いる現実を、「善し悪し」に対する反論と言う形で述べられている
> 事なんですね。意図的かどうかはわかりませんが、電子のお針箱さ
> んが、開き直って悪を是としていると思われかねないことをわざわ
> ざそれを述べられる理由はまったくわからないです。

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) wrote:
> あの箱氏の主張って、結局、いい加減にプログラムしていいって以外に
> 解釈しようがないような...
>
> やっぱり、
> 「必要な知識は、ちゃんと身に付ける」
> だよね。

[Hiroyuki Minesita]

From article <23682.9...@rananim.ie.u-ryukyu.ac.jp>
by ko...@ie.u-ryukyu.ac.jp

> In article <8i6n8g$nm8$1...@sunny.njk.co.jp> ,
> mine...@rd.njk.co.jp (Hiroyuki Minesita) writes
> >　「全部を知る必要は無いよね？」
> >　「だって、必要のある事だけ知っていれば事足りるでしょ？」

> この二つって両立しないと僕は感じますね。というか、両方信じているなら、
> 必要のある事を、全部知る必要はない
> っていうループを廻すと、必要なところがどんどん減っていく...

　「全部」の中に「必要な事」があって、「必要な事」を
「必要な事全部」と言い換えた後にその中の「全部」だけ
取り出してループさせても意味は無いです。
　集合論だか文章論だかの論証をしている訳ではありませ
んので。

> あの箱氏の主張って、結局、いい加減にプログラムしていいって以外に
> 解釈しようがないような...

　そんな事は言っていないと思いますけど。
　むしろですね、freeが不要と言う人の理由に「間違えて
freeするといけないから」なんて言うのがありましたけど
そう言う自分が何を作っているのか判っていなくて良しと
する様な意見こそ、「いい加減にプログラムしていい」っ
て言っている様にしか思えません。
＃freeが不要と言う人の中にそう言う人がいるのはしょう
＃がないとして、そう言う人を他のfreeが不要と言う人が
＃見咎める事が無かった様だったのが、なんか気持ち悪い
＃です。

> やっぱり、
> 「必要な知識は、ちゃんと身に付ける」
> だよね。

　で、その「必要」とは「全部」とイコールなのでしょう
か？

[Shin-ichi TSURUTA]

峯下さん、こんにちは、鶴田(SYN)です。

mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> From article <23682.9...@rananim.ie.u-ryukyu.ac.jp>
> by ko...@ie.u-ryukyu.ac.jp

> > あの箱氏の主張って、結局、いい加減にプログラムしていいって以外に
> > 解釈しようがないような...
>
> 　そんな事は言っていないと思いますけど。

言っていないから、「解釈」なのです。

[kuroda]

黒田たかきです。

Shinji KONO <ko...@ie.u-ryukyu.ac.jp> wrote in message news:23682.9...@rananim.ie.u-ryukyu.ac.jp...
> >　「全部を知る必要は無いよね？」
> >　「だって、必要のある事だけ知っていれば事足りるでしょ？」
> やっぱり、
> 「必要な知識は、ちゃんと身に付ける」
> だよね。

その「必要な知識」が何かという話ですよね。

自転車は必要だよね。自転車の乗り方は覚えなくっちゃ。
自転車で怪我することもあるよね。自転車の危険と回避方法も知らなくっちゃ。

似たもので一輪車というのもあるけど、
お父さんから「あれは危険だから使っちゃ駄目です」って言われた。
どうしても一輪車に乗りたくなるまでは、乗らないのだから、
どう危険なのか、どう回避するのか、を知る必要はない。

一輪車の知識は「必要な知識」か？
＃ 自転車の危険と、一輪車の危険は、共通する点が多いかもしれない。
＃ でも、それらは自転車に乗る前に覚えるので問題じゃない。

--
----
■■ 黒田たかき
■■ kur...@sdl.hitachi.co.jp

[oka...@cs.ehime-u.ac.jp]

岡久です。

<8i9boq$7fv$1...@sunny.njk.co.jp>の記事において
mine...@rd.njk.co.jpさんは書きました。

>> 　むしろですね、freeが不要と言う人の理由に「間違えて
>> freeするといけないから」なんて言うのがありましたけど
>> そう言う自分が何を作っているのか判っていなくて良しと
>> する様な意見こそ、「いい加減にプログラムしていい」っ
>> て言っている様にしか思えません。

exit のことを無視しているようですね。これで何度目だろ
う...

何を作っているのか分かっているからこそ、省略できるもの
は省略できます。理由も考えずに free すれば万事 OK と信じ
込んでいてはできないですよね。

UNIX や Windows のような OS では、exit 直前の free は必
須ではありません。もちろん、free してもいいですよ。

exit 直前の free は、調べれば、exit がうまく面倒見てく
れるので、呼ばなくても大丈夫だと分かります。それが分かっ
ても、常に間違い無く free しないといけないのでしょうか?

scanf は、理由を調べず避けてもかまわないが、free は理
由を知っていても避けたらいけないのでしょうか?

--
Email: oka...@cs.ehime-u.ac.jp

[Hiroyuki Minesita]

From article <8iaoba$3hb$1...@csgw2.cs.ehime-u.ac.jp>
by oka...@cs.ehime-u.ac.jp

> <8i9boq$7fv$1...@sunny.njk.co.jp>の記事において
> mine...@rd.njk.co.jpさんは書きました。
> >> 　むしろですね、freeが不要と言う人の理由に「間違えて
> >> freeするといけないから」なんて言うのがありましたけど
> >> そう言う自分が何を作っているのか判っていなくて良しと
> >> する様な意見こそ、「いい加減にプログラムしていい」っ
> >> て言っている様にしか思えません。

> exit のことを無視しているようですね。これで何度目だろ
> う...

　そう言う問題じゃない記事があったのですよ。
　その記事には「間違ってfreeしたら対処不能になる」とか言う
書き方をしていたと思いますけど。
＃「なんでデバッグできないのよ？」

> UNIX や Windows のような OS では、exit 直前の free は必
> 須ではありません。もちろん、free してもいいですよ。

　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。

> exit 直前の free は、調べれば、exit がうまく面倒見てく
> れるので、呼ばなくても大丈夫だと分かります。それが分かっ
> ても、常に間違い無く free しないといけないのでしょうか?
>
> scanf は、理由を調べず避けてもかまわないが、free は理
> 由を知っていても避けたらいけないのでしょうか?

　特にMS-Windows系のプラットフォームでの受注生産の大規模な
業務アプリケーションだと、確保したものは必ず開放する事を
「アプリケーションのレイヤ」で保証しないと、不許可を出され
ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
らないのです。
　ライブラリの中はあくまでブラックボックスとして扱い、その
実装なんて関係有りません。アプリケーションからどう見えるか
だけが問題になります。
　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
とか新人に教える方が現場では害になる事さえあり得ます。

　結局、研究者と現場では思想が違うんだから、どっちが普遍的
に正しいなんて話じゃ無い訳で、「研究者の思想が全て」みたい
な話になってしまうと現場は困るのですよ。

＃電子のお針箱氏も結局そう言う見方なんだと思いますけど。

[Sugihara Yoshimi]

<oka...@cs.ehime-u.ac.jp> wrote in message
news:8iaoba$3hb$1...@csgw2.cs.ehime-u.ac.jp...
> 岡久です。

>
> <8i9boq$7fv$1...@sunny.njk.co.jp>の記事において
> mine...@rd.njk.co.jpさんは書きました。
> >> 　むしろですね、freeが不要と言う人の理由に「間違えて
> >> freeするといけないから」なんて言うのがありましたけど
> >> そう言う自分が何を作っているのか判っていなくて良しと
> >> する様な意見こそ、「いい加減にプログラムしていい」っ
> >> て言っている様にしか思えません。
>
>
> exit のことを無視しているようですね。これで何度目だろ
> う...
>

> 何を作っているのか分かっているからこそ、省略できるもの
> は省略できます。理由も考えずに free すれば万事 OK と信じ
> 込んでいてはできないですよね。
>

> UNIX や Windows のような OS では、exit 直前の free は必
> 須ではありません。もちろん、free してもいいですよ。
>

> exit 直前の free は、調べれば、exit がうまく面倒見てく
> れるので、呼ばなくても大丈夫だと分かります。それが分かっ
> ても、常に間違い無く free しないといけないのでしょうか?
>
> scanf は、理由を調べず避けてもかまわないが、free は理
> 由を知っていても避けたらいけないのでしょうか?

何度も出てると思うのですが
ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのですが
ｍａｌｌｏｃで確保したメモリを開放するという記述はありません
＃ＶｉｓｕａｌＣ＋＋ヘルプで確認

この点についてはどうお考えなのでしょう
ＵＮＩＸやWindowsではうまく動作すると言われても
ｅｘｉｔの仕様に無い動作を期待することは問題ではないですか？

ちゃんとｅｘｉｔの仕様を読んでますか？
ｅｘｉｔの仕様を読んでいれば

> exit 直前の free は、調べれば、exit がうまく面倒見てく
> れるので、呼ばなくても大丈夫だと分かります。それが分かっ
> ても、常に間違い無く free しないといけないのでしょうか?

という話には説得力がぜんぜん無いと思うのですが
＃実装上問題ないのは理解してます

[Shin-ichi TSURUTA]

峯下さん、こんにちは、鶴田(SYN)です。

mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> > UNIX や Windows のような OS では、exit 直前の free は必
> > 須ではありません。もちろん、free してもいいですよ。
>

> 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。

教え方に問題があります。
「どんな時もexitの前で必ずfreeしなければならない。」
は駄目です。

> > exit 直前の free は、調べれば、exit がうまく面倒見てく
> > れるので、呼ばなくても大丈夫だと分かります。それが分かっ
> > ても、常に間違い無く free しないといけないのでしょうか?
> >
> > scanf は、理由を調べず避けてもかまわないが、free は理
> > 由を知っていても避けたらいけないのでしょうか?
>

> 　特にMS-Windows系のプラットフォームでの受注生産の大規模な
> 業務アプリケーションだと、確保したものは必ず開放する事を
> 「アプリケーションのレイヤ」で保証しないと、不許可を出され
> ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
> らないのです。
> 　ライブラリの中はあくまでブラックボックスとして扱い、その
> 実装なんて関係有りません。アプリケーションからどう見えるか
> だけが問題になります。

そういう場合の時のことについて誰も異議を唱えてはおりませんが？

> 　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
> とか新人に教える方が現場では害になる事さえあり得ます。

そんなこと、みんなわかっています。

> 　結局、研究者と現場では思想が違うんだから、どっちが普遍的
> に正しいなんて話じゃ無い訳で、「研究者の思想が全て」みたい
> な話になってしまうと現場は困るのですよ。
>
> ＃電子のお針箱氏も結局そう言う見方なんだと思いますけど。

違います。必要以上に一般化しようとしているから問題なんです。

[Hiroyuki Minesita]

From article <8ic3mn$hq6$1...@nwms2.odn.ne.jp>
by Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp>

> mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> > > UNIX や Windows のような OS では、exit 直前の free は必
> > > 須ではありません。もちろん、free してもいいですよ。

> > 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。

> 教え方に問題があります。
> 「どんな時もexitの前で必ずfreeしなければならない。」
> は駄目です。

　exitの前かどうかの区別なんて言うはずが無いです。

> > 　ライブラリの中はあくまでブラックボックスとして扱い、その
> > 実装なんて関係有りません。アプリケーションからどう見えるか
> > だけが問題になります。

> そういう場合の時のことについて誰も異議を唱えてはおりませんが？

　力一杯異議だらけだったと思いますが？
　私の見たところはこんな感じです。

　「現場ってこんなもんなのよ」
　「そんなん普通じゃないんだから議論の余地なんて無いよ」
　「あのね、現実がそこにあるでしょ？」
　「だから、なんでそんな現実をみなきゃなんないの？」
　「現実を見なくてどうすんのよ」
　「知らないよ、兎に角そんな現実は認められないね」

　って、なっているんですけど。

> > 　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
> > とか新人に教える方が現場では害になる事さえあり得ます。

> そんなこと、みんなわかっています。

　じゃ、なんで電子のお針箱氏の意見に反論が続くんでしょう？

> > 　結局、研究者と現場では思想が違うんだから、どっちが普遍的
> > に正しいなんて話じゃ無い訳で、「研究者の思想が全て」みたい
> > な話になってしまうと現場は困るのですよ。

> > ＃電子のお針箱氏も結局そう言う見方なんだと思いますけど。

> 違います。必要以上に一般化しようとしているから問題なんです。

　逆から見れば研究者の思想を必要以上に一般化している様に
見えます。
＃見ているものが違うんですよ。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8ic12j$96q$1...@news.kyosai.or.jp> の
記事において 2000年06月16日(金) 10時27分44秒頃、
"Sugihara Yoshimi" <sugi...@kyosai.or.jp>さんは書きました。

>ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのですが
>ｍａｌｌｏｃで確保したメモリを開放するという記述はありません
>＃ＶｉｓｕａｌＣ＋＋ヘルプで確認
>
>この点についてはどうお考えなのでしょう
>ＵＮＩＸやWindowsではうまく動作すると言われても
>ｅｘｉｔの仕様に無い動作を期待することは問題ではないですか？

exit()にソレを期待できなくても、プロセスの終了「に」
ソレを期待することが出来るぞ、という文脈なのだと
理解していました。

言語が(ってのもヘンな言いかただが)捕まえたモノを
放させる手段が、言語の中にしかない、とは限らない
ということなんじゃないんでしょうか？

＃エントロピーギャップ(?)が生じるんでキモチワルイ
＃ってのは賛同しますが(^^;、キモチワルサに耐えて
＃より良い(笑)実装を選択するのも、エンヂニァ道なのかも。

あ。そう考えると、

>> exit 直前の free は、調べれば、exit がうまく面倒見てく

これってマズイってことなのかな。
面倒見てくれるのがexit()なのかどうかはアレだ、と。

＃あれ？そういう話だったんだっけ？

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <8ic68p$nei$1...@sunny.njk.co.jp> ,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes
>> 「どんな時もexitの前で必ずfreeしなければならない。」
>> は駄目です。
>　exitの前かどうかの区別なんて言うはずが無いです。

え? なんででしょう。

>　逆から見れば研究者の思想を必要以上に一般化している様に
>見えます。
>＃見ているものが違うんですよ。

うーん、そういう問題なのかなぁ。

問題が、

必要な知識とは、どのようなものなのか?

ってことならば、もっと違う議論であっていいような気がする。

例えば、

malloc()/free() の使い方に関して、
プロセスの理解は必要か?

とか聞くのだと思うんだけど... 僕に取っては、この答えは当然 Yes
ですけど、違う人もいるみたいですね。

[KATAYAMA Yoshio]

In article <8ic0ck$keh$1...@sunny.njk.co.jp>,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes:

>　特にMS-Windows系のプラットフォームでの受注生産の大規模な
>業務アプリケーションだと、確保したものは必ず開放する事を
>「アプリケーションのレイヤ」で保証しないと、不許可を出され
>ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
>らないのです。

これを保証するためには、すべてのシグナルを拾って、シグナルによる
異常終了（強制終了）が起きないようにしなければなりません。また、
獲得したすべての資源を、そのシグナルハンドラーで解放できるように
しておかなければなりません。

UNIX の SIGKILL のように、シグナルハンドラーが拾えないシグナルが
存在するシステムの場合は、これは実現できません。「MS-Windows系の
プラットフォーム」には、そのようなシグナルは存在しないのでしょう
か。

本当に「『アプリケーションのレイヤ』で保証」できるのですか。
--
片山＠ＰＦＵ

[Hiroyuki Minesita]

From article <26833.9...@rananim.ie.u-ryukyu.ac.jp>
by ko...@ie.u-ryukyu.ac.jp

> In article <8ic68p$nei$1...@sunny.njk.co.jp> ,
> mine...@rd.njk.co.jp (Hiroyuki Minesita) writes
> >> 「どんな時もexitの前で必ずfreeしなければならない。」
> >> は駄目です。

> >　exitの前かどうかの区別なんて言うはずが無いです。

> え? なんででしょう。

　それは過去に電子のお針箱氏がさんざん説明しています。
　けど、対極の思想の向きには全く理解されてないみたい
です。
＃何故そんなに否定したいのか謎でした。

> >　逆から見れば研究者の思想を必要以上に一般化している様に
> >見えます。
> >＃見ているものが違うんですよ。

> うーん、そういう問題なのかなぁ。

　スレッドが長い理由はそんな所です。

> 問題が、
>
> 必要な知識とは、どのようなものなのか?
>
> ってことならば、もっと違う議論であっていいような気がする。

　scanfに話題が転がった後は、必要なのがどの範囲なのかが
対象だった気もします。
＃けどやっぱり見ているものが違うとしか思えません。

> 例えば、
>
> malloc()/free() の使い方に関して、
> プロセスの理解は必要か?
>
> とか聞くのだと思うんだけど... 僕に取っては、この答えは当然 Yes
> ですけど、違う人もいるみたいですね。

　私はNoです。
　開発の前提自体にNoである必要があるのも一つの理由。
　レイヤが違うのがそもそもの理由。

　勿論、知っていた方が応用が利くとは思うのですが、必須
ではないし、必須であっては困ると言うのもある……。
＃この「必須であっては困る」って所に引っかかるんでしょ
＃うねぇ、きっと。(^^;

[KATAYAMA Yoshio]

In article <8ic12j$96q$1...@news.kyosai.or.jp>,
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:

>ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのですが
>ｍａｌｌｏｃで確保したメモリを開放するという記述はありません

free() を自動的に呼出すというわけではありませんから、exit() の記
述に含まれないのは当然です。また、C 言語の規格でも記述されていま
せん。

>ＵＮＩＸやWindowsではうまく動作すると言われても
>ｅｘｉｔの仕様に無い動作を期待することは問題ではないですか？

exit()（C のライブラリー関数）の仕様ではなく、OS のプログラム終
了処理の仕様の話です。

もし、「exit() の直前でも free() しなければならない（e.g. それ以
降のシステムの挙動が不安定になる）」システムがあったとすると、そ
のシステムでは、シグナルによるプログラムの異常終了（e.g. 端末割
り込み）が起こせないことになります。

＃異常終了時には free() できないため

そのようなシステムであっても、正常終了と異常終了の区別が付けられ
るなら、conforming hosted evironment にすることができます。

また、「exit() の直前に free() しても、プログラム終了時に正常終
了か異常終了かを通知して、あとの動作は保証しない」システムであっ
ても、conforming hosted evironment にすることができます。

＃どちらも、C 言語の規格が期待しているシステムではないでしょう

>ちゃんとｅｘｉｔの仕様を読んでますか？
>ｅｘｉｔの仕様を読んでいれば

free() してから exit() すれば大丈夫などということも書かれていな
いことが分かるはずです。

malloc() や free() の記述に「exit() する前に free() しなければな
らない」と書かれていないことが、「free() せずに exit() すること
が規格に準拠してる」ことの根拠です。
--
片山＠ＰＦＵ

[Hiroyuki Minesita]

From article <KATE.00Ju...@yamato.trad.pfu.co.jp>
by ka...@pfu.co.jp

> >　特にMS-Windows系のプラットフォームでの受注生産の大規模な
> >業務アプリケーションだと、確保したものは必ず開放する事を
> >「アプリケーションのレイヤ」で保証しないと、不許可を出され
> >ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
> >らないのです。

> これを保証するためには、すべてのシグナルを拾って、シグナルによる
> 異常終了（強制終了）が起きないようにしなければなりません。また、
> 獲得したすべての資源を、そのシグナルハンドラーで解放できるように
> しておかなければなりません。

　ここで言っているのは正常にアプリケーションの終了処理
に流れている場合の事にはなります。実際の所、トラップし
た場合はアプリケーションはお手上げです。
　でも、トラップが起きるとバグなので改修が入ります。
　つまり、アプリケーションが原因でトラップが発生する事
が無い事も保証しなきゃいけない、って事になります。(^^;

＃他人の所為だったら……（言わない方がいいでしょう）(^^;

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <KATE.00Ju...@yamato.trad.pfu.co.jp> ,
ka...@pfu.co.jp (KATAYAMA Yoshio) writes
>本当に「『アプリケーションのレイヤ』で保証」できるのですか。

きっとそんな風に考えるのは、研究者だけなのかも.... 現場のプ
ログラマがどんな風に考えているかは、あまり聞かない方が幸せか
も知れませんね。

たぶん、本当の大規模アプリケーションだったら、なんらかの階層
型メモリ管理が導入されているはずです。でないと、パフォーマン
スもでないでしょうから。

その時に、

どんなメモリ管理を採用しているのかに関わりなく、
malloc()/free()を使用する

とか言われちゃうと、結構、頭を抱えちゃう...

RTOS には、RTOS に適したメモリ管理手法
Unix Process には、Unix Process に適したメモリ管理手法
Windows Thread には、Windows Thread に適したメモリ管理手法
モジュール単位の管理手法
分散アプリケーションでのメモリ/資源管理手法

があるのは当然であって、

malloc()/free() は、メモリ管理の中では、比較的小規模アプリケーション
に適した API であって、それだけを知っているのでは不十分

ってわけです。

僕は、malloc()/free() は、もともと、「exit() の前に free()
しない」ことを前提に設計された API だと思います。そうでなけ
れば、僕だったら、free_all() みたいなAPI を付け加えておきま
す。それを実装することは自体は極めて簡単です。何故、free_all()
が、付いてないかってことを考えるべきですよね。

[KATAYAMA Yoshio]

In article <8icbts$qhe$1...@sunny.njk.co.jp>,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes:

>> >「アプリケーションのレイヤ」で保証しないと、不許可を出され
>> >ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
>> >らないのです。

>> これを保証するためには、すべてのシグナルを拾って、シグナルによる
>> 異常終了（強制終了）が起きないようにしなければなりません。また、

>　ここで言っているのは正常にアプリケーションの終了処理

>に流れている場合の事にはなります。実際の所、トラップし
>た場合はアプリケーションはお手上げです。
>　でも、トラップが起きるとバグなので改修が入ります。

端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関
係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
いわけです。それを「保証する」と言うのが現場というわけでしょうか。

>　つまり、アプリケーションが原因でトラップが発生する事
>が無い事も保証しなきゃいけない、って事になります。(^^;

それは当然でしょう。

例えば、「コマンド引数を間違えたので、そのプログラムを殺したらシ
ステムが発狂した」というのが許される世界なのですか？ということで
す。

＃ Windos って、そんなものかもしれない、、、
--
片山＠ＰＦＵ

[ohsaki takayuki]

In article <8ic12j$96q$1...@news.kyosai.or.jp>, sugi...@kyosai.or.jp says...

>何度も出てると思うのですが
>ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのですが
>ｍａｌｌｏｃで確保したメモリを開放するという記述はありません
>＃ＶｉｓｕａｌＣ＋＋ヘルプで確認

間違いなく開放されます。
#VisualC++のHelpの記述は読んでいませんが... :-)

malloc は、どこからメモリーを調達するか？
もちろん heap 領域からですよね
じゃあ、heap 領域 ってなんでしょう。?
heap 領域の持ち主は?

このへんがわかれば
おのずから出る結論なんです。
#だからHelpには書いてないんだと思います。

あと関係はありませんが、heap ってなんでしょう?
メモリーとheapがどう関係している?
#勉強する価値はあると思います。
------------------------------------------------------
(株) シーエーシー 大崎 貴之 ohs...@cacnet.cac.co.jp

[Hiroyuki Minesita]

From article <KATE.00Ju...@yamato.trad.pfu.co.jp>
by ka...@pfu.co.jp

> 端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関

> 係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
> いわけです。それを「保証する」と言うのが現場というわけでしょうか。

　もう一寸身も蓋もなく言えば「自分の所為で死んだら駄目」
って事です。

> 例えば、「コマンド引数を間違えたので、そのプログラムを殺したらシ
> ステムが発狂した」というのが許される世界なのですか？ということで
> す。

　他人の所為でしょう？

＃だから「言わない方がいい」んですよ。

[Shin-ichi TSURUTA]

峯下さん、こんにちは、鶴田(SYN)です。

mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
>
> From article <8ic3mn$hq6$1...@nwms2.odn.ne.jp>
> by Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp>
>
> > mine...@rd.njk.co.jp (Hiroyuki Minesita) wrote:
> > > > UNIX や Windows のような OS では、exit 直前の free は必
> > > > 須ではありません。もちろん、free してもいいですよ。
>
> > > 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。
>
> > 教え方に問題があります。
> > 「どんな時もexitの前で必ずfreeしなければならない。」
> > は駄目です。
>
> 　exitの前かどうかの区別なんて言うはずが無いです。

それ以上に一般化する人はもっと駄目な人ですね。

> > > 　ライブラリの中はあくまでブラックボックスとして扱い、その
> > > 実装なんて関係有りません。アプリケーションからどう見えるか
> > > だけが問題になります。
>
> > そういう場合の時のことについて誰も異議を唱えてはおりませんが？
>
> 　力一杯異議だらけだったと思いますが？
> 　私の見たところはこんな感じです。
>
> 　「現場ってこんなもんなのよ」
> 　「そんなん普通じゃないんだから議論の余地なんて無いよ」
> 　「あのね、現実がそこにあるでしょ？」
> 　「だから、なんでそんな現実をみなきゃなんないの？」
> 　「現実を見なくてどうすんのよ」
> 　「知らないよ、兎に角そんな現実は認められないね」
>
> 　って、なっているんですけど。

あ、それ、あなたの勘違いです。

> > > 　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
> > > とか新人に教える方が現場では害になる事さえあり得ます。
>
> > そんなこと、みんなわかっています。
>
> 　じゃ、なんで電子のお針箱氏の意見に反論が続くんでしょう？

違いますね。電子のお針箱氏が、事実を述べただけの、反論になら
ない反論をしているにすぎません。

> > > 　結局、研究者と現場では思想が違うんだから、どっちが普遍的
> > > に正しいなんて話じゃ無い訳で、「研究者の思想が全て」みたい
> > > な話になってしまうと現場は困るのですよ。
>
> > > ＃電子のお針箱氏も結局そう言う見方なんだと思いますけど。
>
> > 違います。必要以上に一般化しようとしているから問題なんです。
>
> 　逆から見れば研究者の思想を必要以上に一般化している様に
> 見えます。

何言ってんだか。現場というのも一般化できないんですってば。
研究者(といってもいろいろある)の場所も現場の中の一つですよ。

現場、現場、なんていっていますが、「特定の現場の思想が全て」
みたいな話で、他の現場を混乱させているんですってば。

> ＃見ているものが違うんですよ。

# 井の中の蛙、大海を知らず。ただ空の青のみを知る。

[Hiroyuki Minesita]

From article <8ici8i$adh$1...@nwms2.odn.ne.jp>
by Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp>

> 何言ってんだか。現場というのも一般化できないんですってば。
> 研究者(といってもいろいろある)の場所も現場の中の一つですよ。

　そりゃそうですね……（でもどういい分けたものか……）

> 現場、現場、なんていっていますが、「特定の現場の思想が全て」
> みたいな話で、他の現場を混乱させているんですってば。

　どっちからみてもそう見えるっちゅー事になりますね。

> > ＃見ているものが違うんですよ。
>
> # 井の中の蛙、大海を知らず。ただ空の青のみを知る。

＃井戸が違うだけですな。

[ohsaki takayuki]

In article <26833.9...@rananim.ie.u-ryukyu.ac.jp>, ko...@ie.u-ryukyu.ac.jp
says...

>問題が、
>
> 必要な知識とは、どのようなものなのか?
>
>ってことならば、もっと違う議論であっていいような気がする。
>

>例えば、
>
> malloc()/free() の使い方に関して、
> プロセスの理解は必要か?
>
>とか聞くのだと思うんだけど... 僕に取っては、この答えは当然 Yes
>ですけど、違う人もいるみたいですね。

(プロセスを理解してない人にもプログラムを書いてもらわなければなら
ない立場としては)

「必要か」を「望ましいか」に置き換えれば、反対しないんですが...

私は、「malloc したら 20cm 以内にfree しろ」と言っています。
#エディターが通常のフォントを使っている場合ですが :-)

何も知らない新人に「プロセスの理解」って言うのは、かなり後の話です。
それまでは、

malloc --- 魔法の呪文で、コンピュータに住んでる小人さんが必要な
メモリを用意してくれる.
free --- malloc したら 20cm 以内にfree しないと小人さんの呪いが...

です。 :-)
------------------------------------------------------
(株) シーエーシー 大崎 貴之 ohs...@cac.co.jp

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <8icghf$6...@infonet.sedept.cac.co.jp> ,
ohs...@cac.co.jp (ohsaki takayuki) writes

>(プロセスを理解してない人にもプログラムを書いてもらわなければなら
> ない立場としては)
>「必要か」を「望ましいか」に置き換えれば、反対しないんですが...

おお、あるある。そういう時は、むしろ、
必要なだけmallocする。
なるべく早く終了する。
と教えたほうが良いような気がします。で、Free は教えない :-)

あるいは、その手のプログラムを、モジュールなどで閉じ込めて、
モジュール内専用の(freeしない)malloc を使うとか。

>私は、「malloc したら 20cm 以内にfree しろ」と言っています。
>#エディターが通常のフォントを使っている場合ですが :-)

気分はわかりますけど... でも、それって本当に、正しい教え方
なのかな?

free のない言語は多いですよね。Perl もそうだし、大半の4GL
もそうじゃないでしょうか....

理解できる範囲で使えるツールが今はあるわけで、理解しないで
おまじないのように使うよりは、そちらの方が良いですよね。

[Takemoto,Satoshi]

竹本です。

Shinji KONO wrote:

> おお、あるある。そういう時は、むしろ、
> 必要なだけmallocする。

必要なだけグローバルに定義する、malloc()は教えない
では駄目ですか?(と、このスレッドの元々の主張に戻る。)

もったいないくらいたくさんメモリを取っても、
動的メモリ割当てでメチャクチャされるくらいなら
メモリ増設の出費の方が絶対安くつくと思います。

逆に、そうできないような実行環境(一般のパッケージとか)の場合は、
# そういう状況は少なくなって行くと思うんだけど
時間をかけてちゃんと教えてあげないと、
その人＆以降その人と関わりになる人たち皆が不幸になると思います。

--
竹本 聡 ソニー(株)PNC,PVC,PV4部

[kuroda]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message news:8ici8i$adh$1...@nwms2.odn.ne.jp...

> > > > 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。
> > > 教え方に問題があります。
> > > 「どんな時もexitの前で必ずfreeしなければならない。」
> > > は駄目です。
> > 　exitの前かどうかの区別なんて言うはずが無いです。
> それ以上に一般化する人はもっと駄目な人ですね。

「allocしたら必ずfreeしなければならない。
それがたとえexitの直前だとしても。」
は駄目だと思うけど、
「allocしたら必ずfreeしなければならない。
ただしexitの直前ならfreeしなくていい。」
と言うべきなのでしょうか？
例外的事項を教えるのは普通は後回し。
「allocしたら必ずfreeしなければならない。」
と教えるのでは？とくに「新人」なら。

exit直前のfreeが不要なのは理解できるけど、
exit直前のfreeが悪さをすることがあるのも理解できるけど、
Ｃ／Ｃ＋＋の入門書で「exitの直前ではfreeしなくてもいい」と書いてあるのを、
私は見たことない。

--
----
■■ 黒田たかき
■■ kur...@sdl.hitachi.co.jp

[KATAYAMA Yoshio]

In article <8icfor$sgi$1...@sunny.njk.co.jp>,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes:

>> 例えば、「コマンド引数を間違えたので、そのプログラムを殺したらシ
>> ステムが発狂した」というのが許される世界なのですか？ということで
>> す。

>　他人の所為でしょう？

それが許される「現場」で幸せでしたね。
--
片山＠ＰＦＵ

[ohsaki takayuki]

In article <27482.9...@rananim.ie.u-ryukyu.ac.jp>, ko...@ie.u-ryukyu.ac.jp says...

>おお、あるある。そういう時は、むしろ、
> 必要なだけmallocする。

> なるべく早く終了する。
>と教えたほうが良いような気がします。で、Free は教えない :-)

これは、却下。
常駐プロセスの多い、制御系のプログラムが多かったもので。 :-)

>あるいは、その手のプログラムを、モジュールなどで閉じ込めて、
>モジュール内専用の(freeしない)malloc を使うとか。

これ、造りました。
malloc と同一のコーリングシーケンスの tmpmem ってやつで、結構重宝しま
した。(配列をサイクリックに使うだけ)

#man には「確保したメモリは長い間ほっておくと、腐る」:-)

>>私は、「malloc したら 20cm 以内にfree しろ」と言っています。
>>#エディターが通常のフォントを使っている場合ですが :-)
>
>気分はわかりますけど... でも、それって本当に、正しい教え方
>なのかな?

正しいかどうかは別ですが、必要だったとは思ってます。 ^^;;;

#河野さんとかと違って、普通の人は、最初 C をおぼえるだけで
#大変なんです。 :-)

[ohsaki takayuki]

In article <3949F25B...@cv.sony.co.jp>, take...@cv.sony.co.jp says...

>時間をかけてちゃんと教えてあげないと、
>その人＆以降その人と関わりになる人たち皆が不幸になると思います。

はい、もちろんそうです。
ただ、教えるにも順番とか優先順位があって.....
(受け入れる段階に達していない勉強を要求するのも、かえってかわいそう)

[Sugihara Yoshimi]

"KATAYAMA Yoshio" <ka...@pfu.co.jp> wrote in message
news:KATE.00Ju...@yamato.trad.pfu.co.jp...

> free() してから exit() すれば大丈夫などということも書かれていな
> いことが分かるはずです。
>
> malloc() や free() の記述に「exit() する前に free() しなければな
> らない」と書かれていないことが、「free() せずに exit() すること
> が規格に準拠してる」ことの根拠です。

>「free() せずに exit() することが規格に準拠してる」
は認めます
これについてとやかく言うつもりはありません

ただ、私が問題にしているのは

ｅｘｉｔ（）することによりｍａｌｌｏｃしたメモリが「「　開放　」」される

と言う部分です
記述が無い仕様を「「　期待　」」してるといえませんか？

こういう場合は前にも書いたように

ｍａｌｌｏｃ（）したメモリをｆｒｅｅ（）せずにｅｘｉｔ（）した場合の動作は
そのメモリが開放されても良いし、メモリリークとして残っても良い

と読むのが正しいのではないですか？
＃Ｃ言語の範囲でですが

自分が作成したプログラムの場合で仕様に書いてないことは
「「　適当（自分が考えて妥当）　」」に処理しませんか？
そして、あとから他の人にその部分がおかしいといわれたら
「仕様に無い」といいませんか？

しかしｅｘｉｔ（）の場合には「「　開放されないといけない　」」
と決め付けてるように見受けられます

そのような仕様は書いてないですね
書いてないことは、どうなっても良いということです
＃Ｃ言語の範囲でですが

私の場合、このようなどうなるかわからないプログラムは
使いたくないので、作るときも最大限動作が保証されている
プログラムにしています
＃たまには型破りをやりますが（ウヒヒ）

[Sugihara Yoshimi]

"ohsaki takayuki" <ohs...@cac.co.jp> wrote in message
news:8icbiq$6...@infonet.sedept.cac.co.jp...

> In article <8ic12j$96q$1...@news.kyosai.or.jp>, sugi...@kyosai.or.jp says...
> >何度も出てると思うのですが
> >ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのです
が
> >ｍａｌｌｏｃで確保したメモリを開放するという記述はありません
> >＃ＶｉｓｕａｌＣ＋＋ヘルプで確認
>
> 間違いなく開放されます。
> #VisualC++のHelpの記述は読んでいませんが... :-)
>
> malloc は、どこからメモリーを調達するか？
> もちろん heap 領域からですよね
> じゃあ、heap 領域 ってなんでしょう。?
> heap 領域の持ち主は?

ＶＣ＋＋のｍａｌｌｏｃ（）を見てみました
どこにも

ｈｅａｐから確保します

とは書いて無かったです
＃Ｃ言語の規格書にはそう書いてあるのかな？

書いてないことを期待してはいけません
＃まあｈｅａｐから確保するんだろうが

[Nakamura Akifumi]

中村っす。よだん。

fj.comp.lang.c,fj.comp.lang.c++ の <8ic0ck$keh$1...@sunny.njk.co.jp> の
記事において 2000年06月16日(金) 01時37分24秒頃、
Hiroyuki Minesitaさんは書きました。

>　特にMS-Windows系のプラットフォームでの受注生産の大規模な
>業務アプリケーションだと、確保したものは必ず開放する事を

>「アプリケーションのレイヤ」で保証しないと、不許可を出され
>ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
>らないのです。

恥ずかしいからさ、「受注生産の大規模な業務アプリ」を
前振りとするのは、やめようよ。

なにが(少なくとも俺にとって)恥ずかしいかってーと、
「OSが保証するからしなくていい」という「論理的に正しい」
理由を、論理的に正しくない(笑)他の理由によって抹殺して
いるような、「そんな」プロジェクトを以って、評価基準と
しているところが、(恥ずかしい)です。

＃俺もそういう意味じゃ自らが恥ずかしい。神様ゴメンナサイ。

「受注生産の大規模な業務アプリ」かぁ。
俺の井戸端のささやかな経験を加味した独断と偏見によれば(笑)、
パッケージ入れて売られてるアプリや
「世間に広く使われている(限定(^^;)」フリーソフトとか
より、ナカミのデキという意味では「劣って」いることが
多いんじゃねーかな、と思う。

「そんなのあんたのとこだけでしょ」ってなら、それはその通りかも。
少なくとも「受注生産の以下略」を枕詞にする理由が
なくなるだけのことだから。

＃自称現場の人(笑)の中には、いわゆる(笑)研究者な人を
＃馬鹿にしないと気が済まない人が、いるみたいだ。
＃しかもそれを当然(馬鹿にしてるわけじゃない)と思いこんで
＃いたりするから始末が。

>　ライブラリの中はあくまでブラックボックスとして扱い、その
>実装なんて関係有りません。アプリケーションからどう見えるか
>だけが問題になります。

なんかココ読んだだけで論理破綻しているような気がするなぁ。
きちんと考える脳つーか気力が今無いんで(いつもかな)アレだけど
どこにどうオカシイトコロがあるのかな…うーん…

>　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
>とか新人に教える方が現場では害になる事さえあり得ます。

どんな「害」になっているんですか？
なんとなく、「害の認定のしかた」に微妙な間違いが
あるように思えてならないな。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <27482.9...@rananim.ie.u-ryukyu.ac.jp> の
記事において 2000年06月16日(金) 08時47分02秒頃、
Shinji KONOさんは書きました。

>>私は、「malloc したら 20cm 以内にfree しろ」と言っています。
>>#エディターが通常のフォントを使っている場合ですが :-)

が無理があるのと同じ程度に

> 必要なだけmallocする。
> なるべく早く終了する。
>と教えたほうが良いような気がします。で、Free は教えない :-)

が(実現可能かどうかってーと)無理あるなぁ、という話に
なるだけのような(^^;

方向は全然違うんだけど程度が(笑)同じくらいに、
どっちも無茶というか。

>理解できる範囲で使えるツールが今はあるわけで、理解しないで
>おまじないのように使うよりは、そちらの方が良いですよね。

んですね。おろかな俺が何もしなくても、処理系の中に既に
偉大な先人(笑)の英知が自動的に収納されている奴を
使ったほうが、色々と良さそう。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8ick5t$1ju$1...@sunny.njk.co.jp> の
記事において 2000年06月16日(金) 07時15分09秒頃、
Hiroyuki Minesitaさんは書きました。

>> # 井の中の蛙、大海を知らず。ただ空の青のみを知る。
>＃井戸が違うだけですな。

地下水なんざどうせみんな繋がっています。一つです。
その水飲んで生きているのに、なぜか
水が繋がった状態(海)のことを
表層意識で理解できない人が、多いみたいだ。

＃淡水か海水かっていう問題は忘れてくれ(笑)

そんなに「違う」かなあ？
どっちも似たようなもんなんでねーの？

＃違いを強調したって意味がない場合ってのは、あるよね。

[Nakamura Akifumi]

中村っす。うーいらいら。

fj.comp.lang.c,fj.comp.lang.c++ の <8icfor$sgi$1...@sunny.njk.co.jp> の
記事において 2000年06月16日(金) 05時59分55秒頃、
Hiroyuki Minesitaさんは書きました。

>> 端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関
>> 係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
>> いわけです。それを「保証する」と言うのが現場というわけでしょうか。
>
>　もう一寸身も蓋もなく言えば「自分の所為で死んだら駄目」
>って事です。

おいおい。それが「現場」なんすか？
落ちても構わないが、それがオレのせいだったらヤバイね、というの？
それ「が」許されるんですか？

やっぱり受注のほうがパッケージやフリーみたいな
対外配布(?)ソフトより「アマイ」のかな。
いや、確かに俺たちも、うまくいかねーところを
発注者に「こんな使い方は避けてくださいー」なんてなお願いして
逃避した、ってのはあるような気がするな。うーむアマイぜ。御免。

「身もふたも無い」ことを言えるんだったら、
こんなラクなことはないです。

こんな人(ぉ)がいるから、俺はイイ年こいて尚、「プロ」に
絶望するんだよね。でかい面して実は「金」取ってるっていう
点が違うだけ、なんていう。

ところで、全然知らないけど、例えば飛行機のシステムが
こんなノリで作られてたりしたら、いやだなとは思います。
製鉄所とかも。他にも多数あるだろうな。

[oka...@cs.ehime-u.ac.jp]

岡久です。

<27482.9...@rananim.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。

>> 必要なだけmallocする。
>> なるべく早く終了する。
>> と教えたほうが良いような気がします。で、Free は教えない :-)

冗談なのかもしれませんが、これはまた free 主義者を無用に
刺激していると思います。伸び縮みするデータ構造をループの中
であつかうようなときは、free した方が良いことも多いでしょう。
同じサイズのオブジェクトの生成破棄の繰り返しということもよ
くあることでしょうから。もちろん、十分なメモリがあるなら、
やはり必須ではないのですけれど。

あまり贅沢に使うとスラッシングの問題もあるんですよね。そ
れらの問題が exit 直前に free しないケースならむしろうまく
いき、速くなることがあるから exit 直前には free しなくて良
いというのが河野さんの論ではなかったでしたっけ?

--
Email: oka...@cs.ehime-u.ac.jp

[Tomoaki NISHIYAMA]

"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:

> ｅｘｉｔ（）することによりｍａｌｌｏｃしたメモリが「「　開放　」」される
>
> と言う部分です
> 記述が無い仕様を「「　期待　」」してるといえませんか？

期待しているでしょうね。

> ｍａｌｌｏｃ（）したメモリをｆｒｅｅ（）せずにｅｘｉｔ（）した場合の動作は
> そのメモリが開放されても良いし、メモリリークとして残っても良い
>
> と読むのが正しいのではないですか？

でも、そのように考えるならば、free()してexit()した場合も、
「そのメモリが開放されても良いし、メモリリークとして残っても良い」
わけですね。

> 私の場合、このようなどうなるかわからないプログラムは
> 使いたくないので、作るときも最大限動作が保証されている
> プログラムにしています

だから動作の保証の程度は変わらないのでは?

--
Tomoaki Nishiyama
e-mail:tom...@nibb.ac.jp
National Institute for Basic Biology

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

news:8i8ldp$if1$1...@nwms2.odn.ne.jp...

> > > # 殺人が起る。
> > > # 殺人は良くないよねという議論が起る。
> > > # でも、殺人は起きるよね。という、反論にならない反論が来る。
> > > ## そんなもの肯定してどうするんでしょうかね・・・。
> >
> > 人が死ぬと言うことについて議論している時に...
> >
> > 「殺人によって死ぬ人もいるよね。」
> > 「殺人は良くないから考えるな。」
> >
> > と言われているように感じているのですが...。
>
> 例が悪かったのは、申し訳ないですが、これは逆ですね。良くない
> から「考えろ」「気をつけよう」と申し上げているのですよ。

鶴田さんが主張している、「良くないから「考えろ」「気をつけよう」」と言う意
見に反論しているわけではありません。

ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰った状況が
望ましくないのは確かですし、そう言う状況にならないようにしようと努力/議論す
ることは大切なことですが、それと今現在そう言う状況が存在することと別ですよ
ね。

私は、自分の主張 (関数を使わない時には、必ずしもその理由を知る必要はない)
の根拠として、そう言う状況があると言っているだけです。ですから...

そう言う状況は、これこれすればなくなるはずだから「使わないときでも、ちゃん
と理由を知るべきである。」

と言うような反論であれば、理解できます。(もっとも、これこれが実現可能かと
か有効なのかとかの議論になると思いますが...。)

あるいは、

そう言う状況は、少ないから「ほとんどの場合で、ちゃんと理由を知るべきであ
る。」

と言うような反論であれば、理解できます。

> > # 「峯下博幸」さんの様に正しく解釈されている方がいるのでちょっとは安心し
> > # たのですが、書き方が悪いのかなぁ...。
>
> そうですね。私もそう思っていましたし。適切なフォローがあって
> 助かりました。

そう思っていてなぜに、上記のような発言をなさるのでしょうか ?

また...

> 結局、これにつきるんですね。
...

の投稿内容の意図がよくわかりません。私は、これらの投稿に各々フォローがつけて
あ
りますが、その内容がおかしいと言うことでしょうか ?

以下の投稿にはフォローがまだでしたので...

> ko...@ie.u-ryukyu.ac.jp (Shinji KONO) wrote:
> > あの箱氏の主張って、結局、いい加減にプログラムしていいって以外に
> > 解釈しようがないような...

解釈は人それぞれですが、研究者を自認するのであれば、「どこそこの投稿によ
り、この様にしか解釈できない。」と言うような具体的な指摘はできないものでしょ
うかねぇ ?

--
--------------
電子のお針箱
ue...@di.mbn.or.jp
(From: ヘッダーはスパム対策のため -nospam を付加しています。)
--------------

[Shin-ichi TSURUTA]

黒田さん、こんにちは、鶴田(SYN)です。

"kuroda" <kur...@sdl.hitachi.co.jp> wrote:
>
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message news:8ici8i$adh$1...@nwms2.odn.ne.jp...
> > > > > 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。
> > > > 教え方に問題があります。
> > > > 「どんな時もexitの前で必ずfreeしなければならない。」
> > > > は駄目です。
> > > 　exitの前かどうかの区別なんて言うはずが無いです。
> > それ以上に一般化する人はもっと駄目な人ですね。
>
>
> 「allocしたら必ずfreeしなければならない。
> それがたとえexitの直前だとしても。」
> は駄目だと思うけど、
> 「allocしたら必ずfreeしなければならない。
> ただしexitの直前ならfreeしなくていい。」
> と言うべきなのでしょうか？
> 例外的事項を教えるのは普通は後回し。
> 「allocしたら必ずfreeしなければならない。」
> と教えるのでは？とくに「新人」なら。

「一部の例外を除いて、allocしたらfreeした方がよい、もしくは、
するように心がけよう」

では駄目ですか？「必ず」と言うのは、非常に危険な修飾語ですよ。

絶対にgotoを使うなと言われたため、とんでもない苦労をして深い
ループから抜けるようなコードを書いてしまった場合の責任がとれ
ますか？
# 新人が自ら「おかしい」とか、「特殊な場合出会った」と感じる
# 瞬間を摘み取ってはならないと思います。

> exit直前のfreeが不要なのは理解できるけど、
> exit直前のfreeが悪さをすることがあるのも理解できるけど、
> Ｃ／Ｃ＋＋の入門書で「exitの直前ではfreeしなくてもいい」と書いてあるのを、
> 私は見たことない。

多くの場合、しなくていいこと(無限にありますね)をいちいち書い
たりしません。してはならないことや、しなくてはならないことは
明記されていますが。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

> news:8i8ldp$if1$1...@nwms2.odn.ne.jp...

> > 例が悪かったのは、申し訳ないですが、これは逆ですね。良くない
> > から「考えろ」「気をつけよう」と申し上げているのですよ。
>
> 鶴田さんが主張している、「良くないから「考えろ」「気をつけよう」」と言う意
> 見に反論しているわけではありません。
>
> ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰った状況が
> 望ましくないのは確かですし、そう言う状況にならないようにしようと努力/議論す
> ることは大切なことですが、それと今現在そう言う状況が存在することと別ですよ
> ね。

「善し悪し」というのは、既に「存在」を認めているのです。
そこに「存在」を主張しても、何の情報も提供していないことは理
解出来ますよね？だから、反論にすらならないと申し上げているの
です。議論の階層が違うのです。「存在」の上で「善悪」は成り立
つが、「善悪」の上に「存在」があるのではないのです。
# 間違っても宇宙の創造には行かないように。ツッコミ禁止(^^;
# philosophyなら、喜んで受けますが(爆)

> 私は、自分の主張 (関数を使わない時には、必ずしもその理由を知る必要はない)
> の根拠として、そう言う状況があると言っているだけです。ですから...

議論を振り出しに戻していることが理解出来たでしょうか？

[電子のお針箱]

KATAYAMA Yoshio <ka...@pfu.co.jp> wrote in message
news:KATE.00Ju...@yamato.trad.pfu.co.jp...

> >> >「アプリケーションのレイヤ」で保証しないと、不許可を出され
> >> >ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
> >> >らないのです。
>

> >> これを保証するためには、すべてのシグナルを拾って、シグナルによる
> >> 異常終了（強制終了）が起きないようにしなければなりません。また、
>
> >　ここで言っているのは正常にアプリケーションの終了処理
> >に流れている場合の事にはなります。実際の所、トラップし
> >た場合はアプリケーションはお手上げです。
> >　でも、トラップが起きるとバグなので改修が入ります。
>

> 端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関
> 係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
> いわけです。それを「保証する」と言うのが現場というわけでしょうか。

強制終了等の場合はしょうがないですね。(と言うより、それをアプリケーション
がトラップできたら終了しないアプリケーションが作れてしまいますから...。)

でも、「強制終了などの特殊な場合にできないから、アプリケーションのレイヤー
で確保/解放を閉じることは無駄である」と言うのは、「時速150Kmでぶつかったら、
シートベルトなんて役に立たないから、シートベルトは役に立たない。」と言うのと
同じ様な気がします。

# レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。

ある種の開発環境ではアプリケーションの終了時に、解放していないメモリーを表
示する機能を持っています。レイヤーで閉じておかないと意図しない解放忘れと、意
図的な解放省略が混在してしまいますよね。意図的な解放省略が少ない様な小規模ア
プリケーションなら人手で判断することもできますが、大規模アプリケーションや複
数人で共同開発している場合ではなかなか難しいと思っています。

私の感覚では、上記のメリットが「いちいち free() すると言う手間がかかる」と
言うデメリットを上回っていると思います。

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <8iej7e$t3r$1...@newsjp.mbn.or.jp> ,
電子のお針箱<ueno-...@di.mbn.or.jp> writes

> 強制終了等の場合はしょうがないですね。(と言うより、それをアプリケーション
>がトラップできたら終了しないアプリケーションが作れてしまいますから...。)

「しょうがいないですね」で済ませちゃうんですか? もしかして、
そんな感じで、OS やら、Middleware やら、ライブラリやら作って
いるんでしょうか...

># レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。

なのに、「プロセスという仮想計算機」というレイヤーを軽視する
のは何故なんでしょう... 「仮想計算機というレイヤーがあるから、
exit() の前にfree() しなくて良いことが保証される」というのは、
すごいメリットだと思います。

> 私の感覚では、上記のメリットが「いちいち free() すると言う手間がかかる」と
>言うデメリットを上回っていると思います。

だんだん、「いちいち free() するメリット」って「変な上司を納
得させる」以外にないような気がして来ました。

そういうことならば「現場は大変ですね」というのが正直な感想で
す。僕も、一応、反対意見は出すだろうけど、上司がやれといった
ら、きっと free() するでしょうね。する場合としない場合と時間
を測ってグラフを書くぐらいはするかも知れない。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> # レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。

ここで議論している方は、メリットについては話すまでもなく知っ
ているはずです。議論の余地はありません。一定レベル以上の人間
にとっては情報量０です。
それとも電子のお針箱さんは反論している相手の方を、メリットも
わからないような低レベルな相手だとみなしているのでしょうか？

> ある種の開発環境ではアプリケーションの終了時に、解放していないメモリーを表
> 示する機能を持っています。レイヤーで閉じておかないと意図しない解放忘れと、意
> 図的な解放省略が混在してしまいますよね。意図的な解放省略が少ない様な小規模ア
> プリケーションなら人手で判断することもできますが、大規模アプリケーションや複
> 数人で共同開発している場合ではなかなか難しいと思っています。

意図的な解放省略というのは、同時に意図的な保持でもあります。
意図的な保持を大規模アプリケーションや複数人で共同開発してい
る場合にできないというなら、既に設計能力がないと思います。

> 私の感覚では、上記のメリットが「いちいち free() すると言う手間がかかる」と
> 言うデメリットを上回っていると思います。

また必要以上の一般化をしてますね。freeすべきところでするのは
当然。しかし、何も考えずにfreeしとけばいいや的なコードが、無
駄な資源確保と解放を繰返し、パフォーマンスを著しく損ねる場合
に遭遇したことはないのでしょうか？
# 作業する手間を惜しまないフリをして、考える手間を放棄した思
# 考停止です。参照カウンタ等の有効性は御存知だとは思いますが。

[電子のお針箱]

> > Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> > news:8i8ldp$if1$1...@nwms2.odn.ne.jp...

> > ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰った状
> > 況が望ましくないのは確かですし、そう言う状況にならないようにしようと努

> > 力/議論することは大切なことですが、それと今現在そう言う状況が存在するこ
> > とと別ですよね。
>
> 「善し悪し」というのは、既に「存在」を認めているのです。

これは、正しいです。(存在を否定したことはありませんよ。)

> そこに「存在」を主張しても、何の情報も提供していないことは理
> 解出来ますよね？

これが変。「なぜりんごが落ちるのかなぁ ?」「万有引力があるからだよ。」この
場合も、単に存在を主張しているだけですが情報量は 0 ですか ?

私は、自分の主張の根拠として事実を挙げているのです。その事実の存在の有無を
問題にしているわけではありません。わたしの主張と異なる方が、これらの存在を知
らないのかわたしの主張との関連を見出せないのではないかと言うことで、例として
あげているのです。

もちろん、鶴田さんを含めこれらの存在を認めておられる方に対しては情報量 0
でしょうが、そもそもこの件は鶴田さんへの反論ではありません。

> だから、反論にすらならないと申し上げているのです。議論の階層が違うのです。

上記のごとく、鶴田さんのこの意見は間違ったことに対して反論しています。そっ
くりそのままお返しするしかないです。

> 「存在」の上で「善悪」は成り立つが、「善悪」の上に「存在」があるのではな
> いのです。

わたしのどこの主張から、こう言う解釈を導かれたのでしょうか ? 書き方がまず
いかもしれないので、よろしければ教えていただけますか。

> > 私は、自分の主張 (関数を使わない時には、必ずしもその理由を知る必要はな
> > い)の根拠として、そう言う状況があると言っているだけです。ですから...
>
> 議論を振り出しに戻していることが理解出来たでしょうか？

振り出しの方を、よく見てくださいと言うことです。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> > > Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> > > news:8i8ldp$if1$1...@nwms2.odn.ne.jp...
>
> > > ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰った状
> > > 況が望ましくないのは確かですし、そう言う状況にならないようにしようと努
> > > 力/議論することは大切なことですが、それと今現在そう言う状況が存在するこ
> > > とと別ですよね。
> >
> > 「善し悪し」というのは、既に「存在」を認めているのです。
>
> これは、正しいです。(存在を否定したことはありませんよ。)

それはそうでしょう。電子のお針箱さんの立場で否定したら、議論
から退場ですってば。(^^;

ただ、既に認めているものに対して事実という反論をされるのは、
まるで当方が存在を否定しているかのようにみられるので、それが
困るのです。

> > そこに「存在」を主張しても、何の情報も提供していないことは理
> > 解出来ますよね？
>
> これが変。「なぜりんごが落ちるのかなぁ ?」「万有引力があるからだよ。」この
> 場合も、単に存在を主張しているだけですが情報量は 0 ですか ?

例に合わせるなら、万有引力を既に全員知っているから、情報量０
なんです。存在を知らない人相手に主張するのならともかく、存在
を認めている相手にわざわざおっしゃるのは、馬鹿にしているのか
と思えるほどです。

> 私は、自分の主張の根拠として事実を挙げているのです。その事実の存在の有無を
> 問題にしているわけではありません。わたしの主張と異なる方が、これらの存在を知
> らないのかわたしの主張との関連を見出せないのではないかと言うことで、例として
> あげているのです。

だから、その事実に対して、議論がされているんですよ。
「その事実の存在の有無を問題にしているわけではありません」は、
当方の主張です。あげられた事実はありふれた話で議論の余地はあ
りません。

> もちろん、鶴田さんを含めこれらの存在を認めておられる方に対しては情報量 0
> でしょうが、そもそもこの件は鶴田さんへの反論ではありません。

では、誰に対し、何を反論なさっているのでしょうか？

> > 「存在」の上で「善悪」は成り立つが、「善悪」の上に「存在」があるのではな
> > いのです。
>
> わたしのどこの主張から、こう言う解釈を導かれたのでしょうか ? 書き方がまず
> いかもしれないので、よろしければ教えていただけますか。

「善し悪し」の議論に対し、「事実」という反論をされたからです。
そこでは事実など必要ありません。

> > > 私は、自分の主張 (関数を使わない時には、必ずしもその理由を知る必要はな
> > > い)の根拠として、そう言う状況があると言っているだけです。ですから...
> >
> > 議論を振り出しに戻していることが理解出来たでしょうか？
>
> 振り出しの方を、よく見てくださいと言うことです。

だから、話が進まないのです。やはり確信犯だったか。

[oka...@cs.ehime-u.ac.jp]

岡久です。

<8ic12j$96q$1...@news.kyosai.or.jp>の記事において
sugi...@kyosai.or.jpさんは書きました。

>> 何度も出てると思うのですが
>> ｅｘｉｔの仕様にはファイルバッファをフラッシュするという記述はあるのですが
>> ｍａｌｌｏｃで確保したメモリを開放するという記述はありません
>> ＃ＶｉｓｕａｌＣ＋＋ヘルプで確認

exit それ自身が解放するというのはおかしいという指摘なら
その通りです。だけど、もうすでに「exit によって引き起こさ
れる一連の処理の中で解放される」という説明はしてますから、
そのことを指摘してるのではないのですよね?

>> この点についてはどうお考えなのでしょう
>> ＵＮＩＸやWindowsではうまく動作すると言われても
>> ｅｘｉｔの仕様に無い動作を期待することは問題ではないですか？

VC++ 6 のヘルプで kernel objects という言葉を検索してみ
てください。答えが得られるでしょう。malloc はヒープからメ
モリを確保します。ヒープはカーネルオブジェクトです。カーネ
ルオブジェクトはアプリケーション(すなわちプロセス)終了時に
OS によって解放されます。その他、サンプルプログラムの中に
は malloc だけして free しないまま終了している例が紹介され
ていましたよ。ページは失念してしまいましたが。

何より、malloc のや free のヘルプに、malloc したら必ず
free しなくてはならないとは書いてないですよね。

その他、malloc の実装に使われている HeapAlloc や HeapFree
HeapDestroy のヘルプも参照して見るとよいでしょう。C++ では
デストラクタがオブジェクトを破壊する必要があるが、C ならば、
いちいち HeapFree しなくとも HeapDestroy で一挙に解放できる
と書いてあります。河野さんの言う free_all にあたるものが、
Win32 にはあります。

これだけだと書いてあるだけですので、実際に以下のようなプ
ログラムを走らせて、メモリが解放されているかどうか確認しま
した。

#include <stdio.h>
#include <stdlib.h>

int main()
{
void *p;

p = malloc(10 * 1024 * 1024);
getchar();
return 0;
}

確かに、プロセス起動と同時に未使用メモリが減少し、終了と同
時に増加し、もとのサイズに戻ることが確認されました。

>> ちゃんとｅｘｉｔの仕様を読んでますか？

Windows の仕様の話です。ただ、私の書き方も正確では無かっ
た。正確には Win32 の仕様の話ですね。

これで、exit 直前の free は省略してもかまわないないです
よね?

--
Email: oka...@cs.ehime-u.ac.jp

[Yasuki Arasaki]

<8ic12j$96q$1...@news.kyosai.or.jp>の記事において
sugi...@kyosai.or.jpさんは書きました。

>> 何度も出てると思うのですが

# それに対する反論・再反論・再々反論くらいはすでに出てるような気が
しないでもないですが…

これだけ長く続いてごちゃごちゃしてしまったスレッドなんだから、
「何度も出てる」ことを書くときは前回出たときにその後どうなったのか
のまとめも付けてくれると助かるんだけどなぁと思いました。
単に個人的要望です。
--
新崎康樹@東大院総合
ara...@mns2.c.u-tokyo.ac.jp

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

news:8iepee$qej$1...@nwms2.odn.ne.jp...

> > # レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。
>
> ここで議論している方は、メリットについては話すまでもなく知っ
> ているはずです。議論の余地はありません。一定レベル以上の人間
> にとっては情報量０です。

済みませんが、情報量 0 と思われましたら、読み飛ばしていただけませんか ? 鶴
田さんは情報量 0 と感じられかも知れませんが、メールではありませんから鶴田さ
んにだけ配信されているわけでありません。

# いちいち「この発言は情報量 0」と書くこと自体が、一定レベル以上の人間にとっ
# ては情報量 0 でしょう。そんな発言は、「無視する」のが正しいと思います。

> それとも電子のお針箱さんは反論している相手の方を、メリットも
> わからないような低レベルな相手だとみなしているのでしょうか？

低レベルであると言うような発言をした覚えはありません。片山さんは、C言語の
仕様に対して大変造詣の深い発言をなさっていると思います。ただ、「レイヤーで
閉じる」件に関して、私とは意見の相違があるようです。ですから、議論しましょ
うと言うだけのことです。

> > ある種の開発環境ではアプリケーションの終了時に、解放していないメモリー
> > を表示する機能を持っています。レイヤーで閉じておかないと意図しない解放忘
> > れと、意図的な解放省略が混在してしまいますよね。意図的な解放省略が少ない
> > 様な小規模アプリケーションなら人手で判断することもできますが、大規模アプ
> > リケーションや複数人で共同開発している場合ではなかなか難しいと思っていま

> > す。
>
> 意図的な解放省略というのは、同時に意図的な保持でもあります。
> 意図的な保持を大規模アプリケーションや複数人で共同開発してい
> る場合にできないというなら、既に設計能力がないと思います。

プログラム終了時の話であることを理解されていますか ? プログラム終了時に意
図的な保持をしてどうするのですか ? すぐに、exit() でシステムに返却されます
が...。

> > 私の感覚では、上記のメリットが「いちいち free() すると言う手間がかか
> > る」と言うデメリットを上回っていると思います。
>
> また必要以上の一般化をしてますね。freeすべきところでするのは
> 当然。

確かに、ここの表現は省略し過ぎですね。「プログラム終了直前まで、いちいち
free() すると言う手間がかかる」と言うことです。

> しかし、何も考えずにfreeしとけばいいや的なコードが、無
> 駄な資源確保と解放を繰返し、パフォーマンスを著しく損ねる場合
> に遭遇したことはないのでしょうか？

確かに、私の主張中に「malloc() した領域が不要になったら (* 何も考えずに *)
free() すべきである」と言う記述があるかと思います。ただ、誤解して欲しくない
のですが、これは 「free() する/しない」についてはとりあえず考えないと言うこ
とです。ここで、free() するとなったらその引数や実行場所についてはちゃんと検
討が必要なことは言うまでもありません。

# ですが、言っておかないと「いいかげんな、free() で問題を引き起こす確率が
# 高いと言うデメリットがある」と言うような反論がきますからね。

# なお、上記の文章で「無駄な資源 (* 確保と *) 解放」と書かれていますが、意図
# 的ですか ? free() で資源を確保するような処理系は見たことがないのですけ
# ど...。(デバッグバージョンで、free() 時にログを取るような処理系ならあり得
# そうですけどね。)

また、私は exit() 前に、free() を入れていることによりパフォーマンス上の問
題に遭遇したことは (* ありません *)。

# ここちょっと表現が微妙です。パフォーマンスが著しく損ねているケースはあるか
# もしれませんが、問題になっていないということです。

もちろん私が単に遭遇していないだけであって、そう言う状況もあり得ると考えて
います。そう言う状況に遭遇して、測定によって本当にそれが exit() 前の free()
のせいだと言うことが判明したら、free() を削除すれば良いと思います。(と何度
も書いてあるはずですけど。)

また、上記の「そう言う状況がそれほどあるわけではない」というのは、私の周り
を見た経験的なものです。「そう言う状況がほとんどだよ」と言う環境もある可能性
があります。そう言う環境では、当然 exit() 前の free() を入れることに対するメ
リット/デメリットの比率が変わってくるでしょうから 「exit() 前の free() を入
れないのが当然」と言う意見もあってしかるべきです。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> news:8iepee$qej$1...@nwms2.odn.ne.jp...
>
> > > # レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。
> >
> > ここで議論している方は、メリットについては話すまでもなく知っ
> > ているはずです。議論の余地はありません。一定レベル以上の人間
> > にとっては情報量０です。
>
> 済みませんが、情報量 0 と思われましたら、読み飛ばしていただけませんか ? 鶴
> 田さんは情報量 0 と感じられかも知れませんが、メールではありませんから鶴田さ
> んにだけ配信されているわけでありません。

それは私が判断することです。私は既に提示された事実を踏まえて、
議論を進めようとしているわけであって、それを止めろといわれる
理由はないと思います。

> # いちいち「この発言は情報量 0」と書くこと自体が、一定レベル以上の人間にとっ
> # ては情報量 0 でしょう。そんな発言は、「無視する」のが正しいと思います。

私は無視したくないんです。

> > > ある種の開発環境ではアプリケーションの終了時に、解放していないメモリー
> > > を表示する機能を持っています。レイヤーで閉じておかないと意図しない解放忘
> > > れと、意図的な解放省略が混在してしまいますよね。意図的な解放省略が少ない
> > > 様な小規模アプリケーションなら人手で判断することもできますが、大規模アプ
> > > リケーションや複数人で共同開発している場合ではなかなか難しいと思っていま
> > > す。

> 確かに、私の主張中に「malloc() した領域が不要になったら (* 何も考えずに *)

> free() すべきである」と言う記述があるかと思います。ただ、誤解して欲しくない
> のですが、これは 「free() する/しない」についてはとりあえず考えないと言うこ
> とです。ここで、free() するとなったらその引数や実行場所についてはちゃんと検
> 討が必要なことは言うまでもありません。

なるほど、あまり考えたくないのと、バグを面倒みてくれるツール
に頼りたいからfreeしたいわけですね。それならＯＫです。確かに
そのレベルのスキルの人にとってはfreeは必須かもしれません。

# また以前みたいに、後で安易にexitをreturnに変えてモジュール
# 化したいからとか言い出すかと思った。こりゃ失礼。(^_^;

[電子のお針箱]

Shinji KONO <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:28572.9...@rananim.ie.u-ryukyu.ac.jp...

> > 強制終了等の場合はしょうがないですね。(と言うより、それをアプリケー
> > ションがトラップできたら終了しないアプリケーションが作れてしまいます

> > から...。)
> 「しょうがいないですね」で済ませちゃうんですか? もしかして、
> そんな感じで、OS やら、Middleware やら、ライブラリやら作って
> いるんでしょうか...

アプリケーションプログラムとしてはどうしようもありませんね。もちろん、次回
起動時に残している一時ファイル等を削除することや、取説などのドキュメントに対
処方法を書く等のシステム的アプローチは別問題です。河野さんは SIGKILL でも
ちゃんと終了処理できる Middle ware、ライブラリ や アプリケーションを作れる
と言うのでしょうか ?

> ># レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。
>
> なのに、「プロセスという仮想計算機」というレイヤーを軽視する
> のは何故なんでしょう... 「仮想計算機というレイヤーがあるから、
> exit() の前にfree() しなくて良いことが保証される」というのは、
> すごいメリットだと思います。

もちろん、そうです。軽視しているわけではありません。上記の様な強制終了時に
破綻しないのはこれらのレイヤーでちゃんと保護されているからであることは認識し
ています。ただ私がアプリケーションレイヤーにこだわるのは...

1. アプリケーションレイヤーで閉じることにより、一部の処理系で意図しない解放
忘れを検出しやすくなる。

2. OS のレイヤーがちゃんと閉じていない可能性がある。(Windows の一部のリソー
スで。また、Unix の一部の実装でメモリーリークがあったこともあります。な
お、商用システムでは、OS を一週間に一度リブートするような構成を取ること
もあります。)

と言う理由からです。(要は、階層化されていレイヤーでは各階層でちゃんと閉じて
いることが必要でしょうということです。下位層で漏れているリソースはその上の層
で回収されると思われますが、それを期待することはあまり望ましくないと思いま
す。)

> > 私の感覚では、上記のメリットが「いちいち free() すると言う手間がかか
> >る」と言うデメリットを上回っていると思います。
>

> だんだん、「いちいち free() するメリット」って「変な上司を納
> 得させる」以外にないような気がして来ました。
>
> そういうことならば「現場は大変ですね」というのが正直な感想で
> す。僕も、一応、反対意見は出すだろうけど、上司がやれといった
> ら、きっと free() するでしょうね。する場合としない場合と時間
> を測ってグラフを書くぐらいはするかも知れない。

そうです。そうやって具体的なメリット/デメリットを出して判断すれば良いだけ
のことです。

私は、全ての環境で必ず exit() 前に free() しろなんて言っていません。ある特
定環境では、exit() 前に free() しないことの方が望ましい状況があるかと思いま
す。ただ、私の周りの環境では、exit() 前に free() した方が望ましいと言うだけ
のことです。

私は、その論拠として上記の２点を挙げています。free() が不要であると言われ
る方からは...

1. 余分な free() により、実行効率が低下する。
2. 余分な free() がバグの元になる。

と言う論拠が挙げられています。あとは、これらのメリット/デメリットを総合的に
判断して適切な方法をとれば良いだけです...。と、言うは易しですが、これらの条
件は作るプログラムによって変わりますから、私はほとんどの場合で free() を入
れるのを基本としているだけです。測定によって free() が問題となることがわ
かったらそれを削除することには吝かではありません。

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

news:8ig2uu$da9$1...@nwms2.odn.ne.jp...

> > > > ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰っ
> > > > た状況が望ましくないのは確かですし、そう言う状況にならないようにしよ

> > > > うと努力/議論することは大切なことですが、それと今現在そう言う状況が
> > > > 存在することと別ですよね。
> > >
> > > 「善し悪し」というのは、既に「存在」を認めているのです。
> >
> > これは、正しいです。(存在を否定したことはありませんよ。)
>
> それはそうでしょう。電子のお針箱さんの立場で否定したら、議論
> から退場ですってば。(^^;
>
> ただ、既に認めているものに対して事実という反論をされるのは、
> まるで当方が存在を否定しているかのようにみられるので、それが
> 困るのです。

私は、鶴田さんが存在を否定していると言うような発言はしていないつもりです。
表現上問題がある個所があるかもしれませんので、そう感じられた記事を指摘して
いただけますか ?

> > > そこに「存在」を主張しても、何の情報も提供していないことは理
> > > 解出来ますよね？
> >
> > これが変。「なぜりんごが落ちるのかなぁ ?」「万有引力があるからだよ。」

> > この場合も、単に存在を主張しているだけですが情報量は 0 ですか ?

>
> 例に合わせるなら、万有引力を既に全員知っているから、情報量０
> なんです。存在を知らない人相手に主張するのならともかく、存在
> を認めている相手にわざわざおっしゃるのは、馬鹿にしているのか
> と思えるほどです。

そう言われるのであれば...

1. 万有引力とりんごが落ちることと関係を知らなかった...

--> ああなる程、りんごが落ちるのは万有引力のせいかぁ。よくわかったよ。

2. 万有引力とりんごが落ちることとの関係を既に知っていた...

--> そうだよねぇ。なぜ「りんごがなぜ落ちるか」なんて質問したんだろう...。

の二つの答えしかないでしょう。それに対して、「万有引力なんて当たり前ジャン。
当たり前のことなんか論拠にならないよ。」と言われているのですよ。

# どうすりゃ良いのでしょうか ? 別の論拠を考えて良いのですけど、同じ論理でや
# られそうな気がするし...。

> > 私は、自分の主張の根拠として事実を挙げているのです。その事実の存在の有
> > 無を問題にしているわけではありません。わたしの主張と異なる方が、これらの

> > 存在を知らないのかわたしの主張との関連を見出せないのではないかと言うこと
> > で、例としてあげているのです。
>
> だから、その事実に対して、議論がされているんですよ。

事実の何について議論しようとしているが、明確にしていただけませんか ?

# 私は、その事実自体については論拠として提示しているだけであって、議論して
# いるわけではありません。

> 「その事実の存在の有無を問題にしているわけではありません」は、
> 当方の主張です。あげられた事実はありふれた話で議論の余地はあ
> りません。

私も、鶴田さんも「存在の有無については、その事実は存在している」と言うこと
で一致していることはご同意いただけていると思います。その上で、私はそう言う事
実をわたしの「理由を知らないで関数を使わないことがある」という主張の論拠とし
ています。

> > もちろん、鶴田さんを含めこれらの存在を認めておられる方に対しては情報量
> > 0 でしょうが、そもそもこの件は鶴田さんへの反論ではありません。
>
> では、誰に対し、何を反論なさっているのでしょうか？

岡久さんの <8i1mfg$brl$1...@csgw2.cs.ehime-u.ac.jp> の投稿に対してです。な
お、具体的な内容は、当該投稿に対するフォロー <8i5a9f$dgo$2...@newsjp.mbn.or.jp>
を投稿してありますが、この件については本投稿時点でその後のフォローを見ていま
せん。

> > > 「存在」の上で「善悪」は成り立つが、「善悪」の上に「存在」があるのでは
> > > ないのです。
> >
> > わたしのどこの主張から、こう言う解釈を導かれたのでしょうか ? 書き方が
> > まずいかもしれないので、よろしければ教えていただけますか。
>
> 「善し悪し」の議論に対し、「事実」という反論をされたからです。
> そこでは事実など必要ありません。

良し悪しの議論については、岡久さん側からの反論です。私は、「良し悪しなんか
関係ありません、事実として存在している」と言うことを論拠にしているだけです。

# 良し悪しの議論をなさりたいのであれば、それを明示してスレッドを分けた方が良
# いと思います。(ただ、良いなんていう人が見つかるとは思えませんが...。)

> > > > 私は、自分の主張 (関数を使わない時には、必ずしもその理由を知る必要
> > > > はない)の根拠として、そう言う状況があると言っているだけです。ですか
> > > > ら...
> > >
> > > 議論を振り出しに戻していることが理解出来たでしょうか？
> >
> > 振り出しの方を、よく見てくださいと言うことです。
>
> だから、話が進まないのです。やはり確信犯だったか。

もう少し、頭を冷やされた方が良いと思います。間違ったまま話を進めても仕方あ
りませんよ。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> news:8ig2uu$da9$1...@nwms2.odn.ne.jp...
>
> > > > > ある関数がちゃんと動作しない原因を調べることもできないほど切羽詰っ
> > > > > た状況が望ましくないのは確かですし、そう言う状況にならないようにしよ
> > > > > うと努力/議論することは大切なことですが、それと今現在そう言う状況が
> > > > > 存在することと別ですよね。
> > > >
> > > > 「善し悪し」というのは、既に「存在」を認めているのです。
> > >
> > > これは、正しいです。(存在を否定したことはありませんよ。)
> >
> > それはそうでしょう。電子のお針箱さんの立場で否定したら、議論
> > から退場ですってば。(^^;
> >
> > ただ、既に認めているものに対して事実という反論をされるのは、
> > まるで当方が存在を否定しているかのようにみられるので、それが
> > 困るのです。
>
> 私は、鶴田さんが存在を否定していると言うような発言はしていないつもりです。
> 表現上問題がある個所があるかもしれませんので、そう感じられた記事を指摘して
> いただけますか ?

既にまとめてありますが。
Message-ID: <8i8ldp$if1$1...@nwms2.odn.ne.jp>

> > > > そこに「存在」を主張しても、何の情報も提供していないことは理
> > > > 解出来ますよね？
> > >
> > > これが変。「なぜりんごが落ちるのかなぁ ?」「万有引力があるからだよ。」
> > > この場合も、単に存在を主張しているだけですが情報量は 0 ですか ?
> >
> > 例に合わせるなら、万有引力を既に全員知っているから、情報量０
> > なんです。存在を知らない人相手に主張するのならともかく、存在
> > を認めている相手にわざわざおっしゃるのは、馬鹿にしているのか
> > と思えるほどです。
>
> そう言われるのであれば...
>
> 1. 万有引力とりんごが落ちることと関係を知らなかった...
>
> --> ああなる程、りんごが落ちるのは万有引力のせいかぁ。よくわかったよ。
>
> 2. 万有引力とりんごが落ちることとの関係を既に知っていた...
>
> --> そうだよねぇ。なぜ「りんごがなぜ落ちるか」なんて質問したんだろう...。

そういう質問が問題じゃないので、このアナロジーは不適切。

> の二つの答えしかないでしょう。それに対して、「万有引力なんて当たり前ジャン。
> 当たり前のことなんか論拠にならないよ。」と言われているのですよ。
>
> # どうすりゃ良いのでしょうか ? 別の論拠を考えて良いのですけど、同じ論理でや
> # られそうな気がするし...。

だから、事実に関することは既に終わっているんです。繰り返す必
要無し。

> > > 私は、自分の主張の根拠として事実を挙げているのです。その事実の存在の有
> > > 無を問題にしているわけではありません。わたしの主張と異なる方が、これらの
> > > 存在を知らないのかわたしの主張との関連を見出せないのではないかと言うこと
> > > で、例としてあげているのです。
> >
> > だから、その事実に対して、議論がされているんですよ。
>
> 事実の何について議論しようとしているが、明確にしていただけませんか ?

善し悪し。

> # 私は、その事実自体については論拠として提示しているだけであって、議論して
> # いるわけではありません。

何の論拠として事実を挙げておられるのですか？

> > 「その事実の存在の有無を問題にしているわけではありません」は、
> > 当方の主張です。あげられた事実はありふれた話で議論の余地はあ
> > りません。
>
> 私も、鶴田さんも「存在の有無については、その事実は存在している」と言うこと
> で一致していることはご同意いただけていると思います。その上で、私はそう言う事
> 実をわたしの「理由を知らないで関数を使わないことがある」という主張の論拠とし
> ています。

「理由を知らないで関数を使わないことがある」が主張なら事実はなんですか。
「理由を知らないで関数を使わないことがある」が事実なら主張はなんですか。

以下の空欄を埋めよ。

　主張：

　事実：

で、私は、「使うなといわれただけで、理由を知らないで関数を使
わないことがある」態度は良くないと申し上げているのです。
# ただし、これは、scanfについてであることに注意。

> > > > 「存在」の上で「善悪」は成り立つが、「善悪」の上に「存在」があるのでは
> > > > ないのです。
> > >
> > > わたしのどこの主張から、こう言う解釈を導かれたのでしょうか ? 書き方が
> > > まずいかもしれないので、よろしければ教えていただけますか。
> >
> > 「善し悪し」の議論に対し、「事実」という反論をされたからです。
> > そこでは事実など必要ありません。
>
> 良し悪しの議論については、岡久さん側からの反論です。私は、「良し悪しなんか
> 関係ありません、事実として存在している」と言うことを論拠にしているだけです。

「事実として存在している」と言うことを論拠に何を主張している
のですか？単に駄目な奴がいっぱいいるっていいたいだけ？

oka...@cs.ehime-u.ac.jp wrote:
> ここに、電子お針箱さんの矛盾が集約されています。反論していると言っ
> ておきながら、実際には事実を告白しているだけと言う。それが反論になら
> ないことがお分かりにならないのでしょうか? 電子のお針箱さんは事実だけ
> 告白してさっさと引っ込むべきだったのに、執拗に理由のよく分からない反
> 論を続けているわけです。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。
# おまけ。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> もう少し、頭を冷やされた方が良いと思います。間違ったまま話を進めても仕方あ
> りませんよ。

あはっ、どうしてそう思っちゃったのかな～。電子ちゃん。
さすが、fermionって感じ。

# 人は憶測で他人を見る時、そこに自分自身を見る。

[NEO]

oka...@cs.ehime-u.ac.jp writes:

> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> void *p;
>
> p = malloc(10 * 1024 * 1024);
> getchar();
> return 0;
> }

VC及びWindowsの事は分らないのですが、これだと実際にはメモリの確保はさ
れるけれど、メインメモリは消費されないのではないでしょうか？

Linuxですとmallocでメモリが確保されますが、実際にはその確保領域に書き
込みをした時にメインメモリが消費されます。

僕はfree()しなくて、プログラムが終了しても問題ないと思いますが、プログ
ラム中でメモリをもう一度確保したい場合には、不要になった領域をfree()
しておけば二重に消費する事はないので、出来れば不要になった時にfree()し
ておくのが良いと思います。

p = (int*)malloc(size);
何かの処理
free(p);
p = (int*)malloc(size);
何かの処理

とすれば、この時点でsize分メモリを消費しますが、

p = (int*)malloc(size);
何かの処理
q = (int*)malloc(size);
何かの処理

これですと、size×２の分消費される事になります。当然ですが、最初のsize
分が不要になったとしてです。

--neo

[Shinji KONO]

河野 真治@琉球大情報工学です。(このサブジェクトの意味って、
いったい何を議論しているかわからないって意味だったのね)

もちろん、OS は、リソースリークしないように設計されるべきで、
そうでないのはバグです。もし、リークしないアプリケーションが
書けないってことなら、それは仕様上のバグですよね。

In article <8ii9bm$rmb$1...@newsjp.mbn.or.jp> ,
電子のお針箱<ueno-...@di.mbn.or.jp> writes

> もちろん、そうです。軽視しているわけではありません。上記の様な強制終了時に
>破綻しないのはこれらのレイヤーでちゃんと保護されているからであることは認識し
>ています。ただ私がアプリケーションレイヤーにこだわるのは...

それって、
プロセスレイヤである spwan/fork/exit
の話なのに、何故か、
アプリケーションレイヤにこだわる
話ですよね。それはおかしいんじゃないですか? 二つの階層をごち
ゃごちゃにしているわけでしょう? 上位の階層の解放が、下位の階
層の解放を意味するのは、レイヤを構成するならば必須ですよね。

もし、この二つのレイヤーを完全にネストするならば、

fork() した後に、malloc() でメモリを確保して memcpy() する
exit() する前に free_all() する

まで、するべきかも知れない。そうではなくて、static 領域とか code 領域
とかを気にしないってことなら、単なる自己満足ですよね。そうではなくて、
memcpy() するのは、無駄だと思うんだったら、exit()の前のfree()だって、
同じくらい無駄だと思う。

>1. アプリケーションレイヤーで閉じることにより、一部の処理系で意図しない解放
> 忘れを検出しやすくなる。

それって exit() の前のfree()とは関係ない。レイヤが違うんだから....

>2. OS のレイヤーがちゃんと閉じていない可能性がある。

こっちは、アプリケーションプログラマに関しては、知ったこっちゃなくて、
もし、運悪くそういうOS上でアプリケーションを作ることになったら、

そういうOSのバグに対処するレイヤ/コードを自前で付け加える

ってのが普通じゃないかな。例えば、vi なんかは vi -r があって、
Persistency という意味では不完全な Unix のプロセス/ファイル
の連係をカバーしているわけですよね。

exit(),malloc(),free() を overwrite して、malloc()した領域を
すべて管理する形にして、exit()の前にfree_all() してやれば良
いんですよね? そんな形で形式的に簡単に満たせる「exit()の前の
free()」に、なんの価値もないと僕は思うし、きっと箱氏もそう思
うでしょ?

そうではなくて、
malloc(), free() の対応が重要なんだ
ってことなら、それは、
アプリケーションレイヤでも、単純な対応にならない場合がある
ってのを付け加えないといけません。そこに、exit() の前にfree()
とかの教条的なルールが入る余地はないと思う。

もし、malloc()/free() checker みたいなツールを作ったとして、
(もちろん、完全なcheckは不可能なんだけど.. 限られたプログラ
ムならできるかもしれない) 箱氏は、exit() の前に free() して
ないっていう Warning を出すように作ることに意味があると思う
の?

[okabe katsuyuki]

岡部です。

"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:

> ＶＣ＋＋のｍａｌｌｏｃ（）を見てみました
> どこにも
>
> ｈｅａｐから確保します
>
> とは書いて無かったです
> ＃Ｃ言語の規格書にはそう書いてあるのかな？
>
> 書いてないことを期待してはいけません
> ＃まあｈｅａｐから確保するんだろうが

VC++6のfree()には「OSに返す」とも書いてありませんよね
それじゃどこに返すの？

--
okabe katsuyuki <hgc0...@nifty.ne.jp>
http://member.nifty.ne.jp/wills/

[oka...@cs.ehime-u.ac.jp]

岡久です。

<m3r99v1...@night.narasoft.org>の記事において
ne...@d7.dion.ne.jpさんは書きました。

>> VC及びWindowsの事は分らないのですが、これだと実際にはメモリの確保はさ
>> れるけれど、メインメモリは消費されないのではないでしょうか？
>>
>> Linuxですとmallocでメモリが確保されますが、実際にはその確保領域に書き
>> 込みをした時にメインメモリが消費されます。

これなのですが、VC++ 6 と Borland C++ 5.5 では挙動が
異ります。Borland C++ 5.5 では実際にメモリへの代入等が
あった時に始めて実メモリが消費されるようですが、VC++ 6
では始めから消費されます。デバッグモードやオプションの
有無で変わる可能性はありますね。

>> 僕はfree()しなくて、プログラムが終了しても問題ないと思いますが、プログ
>> ラム中でメモリをもう一度確保したい場合には、不要になった領域をfree()
>> しておけば二重に消費する事はないので、出来れば不要になった時にfree()し
>> ておくのが良いと思います。

はい、その通りです。私は exit 直前の free は必須では
ないし、free しない方が安全だったり高速だったりすること
があると主張しています。あらゆるケースにおいて free を
省くべきとは思いません。

数百万個の要素を持つリンクリストに対するソーティング
をし、それを表示したあと破棄し終了するとします。実際に
は、表示の段階まで行くにもスラッシングにより、かなりの
時間がかかるかもしれませんが、これは避け得ぬことです。
問題は破棄してから終了する段階ですが、一つ一つの要素を
順番に破棄して行くと、ここで再びスラッシング起きて、長
い時間待たされることがあります。そういうときには free
は省略した方がよいでしょう。より賢明であるなら malloc
の利用自身を見直すことになるでしょう。

これは何も私のオリジナルの説明ではなく、Windows にお
ける効率的なメモリ管理とは何かを解説してある書籍に紹介
されていることです。もちろん、UNIX にも当てはまると思い
ます。一度 bucket sort や radix sort を実装して、膨大な
データをソーティングしてみると実感できます。

# radix sort の名誉のために、これはクイックソートより速
# いです。なんせ線形時間で処理が終了しますから。でもリス
# ト処理や要素のコピーのオーバーヘッドが思いのほか大きい。

--
Email: oka...@cs.ehime-u.ac.jp

[Shinji KONO]

河野 真治@琉球大情報工学です。

<m3r99v1...@night.narasoft.org>の記事において
ne...@d7.dion.ne.jpさんは書きました。
> VC及びWindowsの事は分らないのですが、これだと実際にはメモリの確保はさ
> れるけれど、メインメモリは消費されないのではないでしょうか？
> Linuxですとmallocでメモリが確保されますが、実際にはその確保領域に書き
> 込みをした時にメインメモリが消費されます。

この話も、少しレイヤがごっちゃになってませんか?

実メモリはOSが管理
malloc / アプリケーションは仮想メモリのみを管理

ってわけですよね。

もちろん、実メモリをアプリケーション側から管理するAPI はある
んでしょうけど、それはかなり特別でしょう。確かに、いくらレイ
ヤ分けしても、それらは完全に分離されるわけではないんですけど...

In article <8iiu4s$qra$1...@csgw2.cs.ehime-u.ac.jp> ,
oka...@cs.ehime-u.ac.jp writes

> これなのですが、VC++ 6 と Borland C++ 5.5 では挙動が
>異ります。Borland C++ 5.5 では実際にメモリへの代入等が
>あった時に始めて実メモリが消費されるようですが、VC++ 6
>では始めから消費されます。デバッグモードやオプションの
>有無で変わる可能性はありますね。

違うのは OS なんじゃないかなぁ。このあたりを library level で
処理しているとは考えづらいです。そうだとしたら、なんか怖いし。

> はい、その通りです。私は exit 直前の free は必須では
>ないし、free しない方が安全だったり高速だったりすること
>があると主張しています。あらゆるケースにおいて free を
>省くべきとは思いません。

それは、そうだよね。free() するのは、その必要がある時です。
僕は割りとそんな感じ。普通のアプリケーションだと滅多に使わな
いんじゃないかな。もちろん、勝手にnew/destroyしまくる C++ で
はそうはいきませんが。

例えば、コンパイラとかだと、ソース単位にfreeしたりするより、
free しないで、ソース単位のコンパイルは別プロセスにした方が
おそらく高速でしょう。もし、全ソースのフロー解析をするタイプ
だと、おそらく、まったくfreeしないに違いない。個々の最適化モ
ジュールでは、たぶん、それ専用の allocator を用意すると思い
ます。で、たぶん、モジュール内ではこまごま free したりはしな
いでしょう。

[KATAYAMA Yoshio]

In article <8iej7e$t3r$1...@newsjp.mbn.or.jp>,電子のお針箱<ueno-...@di.mbn.or.jp> writes:

>> >> >「アプリケーションのレイヤ」で保証しないと、不許可を出され
>> >> >ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
>> >> >らないのです。

>> >> これを保証するためには、すべてのシグナルを拾って、シグナルによる
>> >> 異常終了（強制終了）が起きないようにしなければなりません。また、

>> 端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関

>> 係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
>> いわけです。それを「保証する」と言うのが現場というわけでしょうか。

> 強制終了等の場合はしょうがないですね。(と言うより、それをアプリケーション
>がトラップできたら終了しないアプリケーションが作れてしまいますから...。)

「しょうがないですね」で済むのを「保証する」と言うのですか。お気
楽な「現場」ですね。

> でも、「強制終了などの特殊な場合にできないから、アプリケーションのレイヤー
>で確保/解放を閉じることは無駄である」と言うのは、「時速150Kmでぶつかったら、
>シートベルトなんて役に立たないから、シートベルトは役に立たない。」と言うのと
>同じ様な気がします。

「強制終了などの保証できない場合もあるのに『保証する』と言えるの
か」と聞いているのです。「シートベルトをしていたら、時速150Kmで
ぶつかっても身体の安全を保証します」と言えるのかということです。
--
片山＠ＰＦＵ

[Hiroyuki Minesita]

From article <20000616195...@nifty.ne.jp>
by BXQ0...@nifty.ne.jp

> 恥ずかしいからさ、「受注生産の大規模な業務アプリ」を
> 前振りとするのは、やめようよ。

　すいません。限定的な状況の下でしか通用しない様な話に
なっているので付けていました。

　結局、状況次第で最善のやり方は変わるものだと言いたかっ
ただけなのですが、極端に走ってしまった様です。

　考えてみると、このニュースグループはＣ／Ｃ＋＋の言語
自体を「目的」にした考え方語るべきで、「手段」でしかな
い考え方を持ち出す方がどうかしていたのかも知れない、と
思っている最中です。(^^;

＃この後はまた状況限定の話ですから、あまり突っ込まない
＃で下さいね。(^^;

> >　ライブラリの中はあくまでブラックボックスとして扱い、その
> >実装なんて関係有りません。アプリケーションからどう見えるか
> >だけが問題になります。

> なんかココ読んだだけで論理破綻しているような気がするなぁ。
> きちんと考える脳つーか気力が今無いんで(いつもかな)アレだけど
> どこにどうオカシイトコロがあるのかな…うーん…

　「実装を知らなきゃ駄目」となるとインターフェース仕様
しか提供されないライブラリを使えなくなってしまう、と言
う事にもなるのでそうなってしまうのです。

> >　だからむしろ下手に、「freeしなくてもＯＳが開放してくれる」
> >とか新人に教える方が現場では害になる事さえあり得ます。

> どんな「害」になっているんですか？
> なんとなく、「害の認定のしかた」に微妙な間違いが
> あるように思えてならないな。

　「必要なfreeをしていないバグの検出が遅れる」とか、
「無くてもいいfreeでも無いと問題にされる」とか、そんな
所です。

＃でも、「絶対にfreeが必要」って言うようなプロジェクト
＃では、malloc/freeの関数は使わないのも事実……(^^;

---
---------------------- 〃
　　　　　　　　　　　ヾ＜・)
峯下博幸　　　　　　　 （ ~彡
---------------------- κκ

[Sugihara Yoshimi]

"okabe katsuyuki" <hgc0...@nifty.ne.jp> wrote in message
news:86og4z3...@hgc02147.nifty.ne.jp...

> 岡部です。
>
> "Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>
> > ＶＣ＋＋のｍａｌｌｏｃ（）を見てみました
> > どこにも
> >
> > ｈｅａｐから確保します
> >
> > とは書いて無かったです
> > ＃Ｃ言語の規格書にはそう書いてあるのかな？
> >
> > 書いてないことを期待してはいけません
> > ＃まあｈｅａｐから確保するんだろうが
>
> VC++6のfree()には「OSに返す」とも書いてありませんよね
> それじゃどこに返すの？

私はＯＳから確保してＯＳへ返すとは一切言ってないです
ＯＳとかを引っ張り出してくるのはｅｘｉｔ（）前はｆｒｅｅ（）しなくても良い
っていってる人たちです
＃ｈｅｒｐから確保されるから大丈夫。。とかね

私は

ｍａｌｌｏｃ（）はあるメモリブロックから指定されたサイズのメモリを
割り当てる関数で、ｆｒｅｅ（）は確保したメモリをメモリブロックへ
返却される

と理解してます

メモリブロックは「「　抽象化　」」しているので、
それがｈｅａｐメモリだろうとグローバルメモリだろうと
実装がどうなってるかなど知ったことではありません
＃逆にいえば、どのように実装されていても良いということです

[Hiroyuki Minesita]

From article <20000616200...@nifty.ne.jp>
by BXQ0...@nifty.ne.jp

> >　もう一寸身も蓋もなく言えば「自分の所為で死んだら駄目」
> >って事です。

> おいおい。それが「現場」なんすか？
> 落ちても構わないが、それがオレのせいだったらヤバイね、というの？
> それ「が」許されるんですか？

　かなり限定された話ですから……
　もう一寸一般的な感覚とすると、実行ファイル中に
５０の関数が有ったとしてその１つか２つだけを貰っ
て作成する、と言うイメージになると思います。

　プログラム全体を見ると、割り込みの様なものを意
識した部分もあるけれど、全く意識しない所もあり、
その全く意識しない部分だけを強調して言っていまし
た。（それがいかんのでしょうけど(^^;）

　それにこの場合、自分の所為か他人の所為か判断す
るまでは解析するとしても、他人の所為の場合は手も
足も出ないし出せないのも事実です。（他社だったり
した場合ですね）

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <8ijt86$lip$1...@sunny.njk.co.jp> ,
mine...@rd.njk.co.jp (Hiroyuki Minesita) writes

>　「実装を知らなきゃ駄目」となるとインターフェース仕様
>しか提供されないライブラリを使えなくなってしまう、と言
>う事にもなるのでそうなってしまうのです。

本当は、バグは「ところ嫌わず」あるわけですから、あるレイヤに
閉じた話ですむのは運が良い話なんですよね。僕は、比較的「全部
のソースがある」仕事しかして来なかったので幸せだったんですが...
マイクロコンピュータ時代は、ソースがなくても、disassemble で
だいたい見当がついたりしましたし。研究関係に来てからは、ほとんど
ソースがあるから... (除く PlayStation 関係)

でも、それは、もちろん、相対的な話であって、

ハードウェア・レイヤ
デバイスドライバ・レイヤ
OS・レイヤ
ライブラリ・レイヤ
サーバ・レイヤ
アプリケーション・レイヤ

は、はっきり分かれていて、その中で閉じたインタフェースがある
のは確かでしょう。この分離がマニュアルに書かれているかという
と、それは、書かれてないんですよね。それは、実装を知らなけれ
ばダメとは少し違うかも知れない。

恐ろしいのは、このあたりを理解してない奴が、レイヤ間のAPI
を設計していたりするときですよね。そうすると、さまざまな
迷信がはびこっちゃう。他のレイヤで処理すべきことって、その
レイヤにとっては、おまじないにしか見えないから。

例えば、mlock で、あるページを実メモリにロックしたとしても、
そのユーザ空間からは、まったく普通のメモリにしか見えません。

>　「必要なfreeをしていないバグの検出が遅れる」とか、
>「無くてもいいfreeでも無いと問題にされる」とか、そんな
>所です。

printf を入れると動くとか、malloc にバグ無しとか、何回目のmalloc
で落ちるかどうかをカウントして、その直前で止めるとか、なんか
もうくだらないテクニックばかり身に付いちゃう... exit の前のfree
とか、malloc したら free とかも、そんな迷信的な技術なんでし
ょう。malloc_debug のありがた味が身にしみるようでは、実はプ
ログラマとしては失格なのかも知れない。でも、プログラムは自分
だけでするわけじゃないから...

>＃でも、「絶対にfreeが必要」って言うようなプロジェクト
>＃では、malloc/freeの関数は使わないのも事実……(^^;

おぉ! どんなものを使うのでしょう。I-TRON では free が必要って
話がありましたよね。

[ohsaki takayuki]

おおさきです。

In article <8ii9bm$rmb$1...@newsjp.mbn.or.jp>, ueno-...@di.mbn.or.jp says...

> 私は、全ての環境で必ず exit() 前に free() しろなんて言っていません。ある特
>定環境では、exit() 前に free() しないことの方が望ましい状況があるかと思いま
>す。ただ、私の周りの環境では、exit() 前に free() した方が望ましいと言うだけ
>のことです。

私も「malloc したら必ずfree」 と言っていますが
#「free 忘れ」には結構悩まされてますので :-)

しかし、exit 時には free しない形としてます。
その理由は、余分なコード(バグの元)が必要になるからです。
#決して、特定環境ではありません :-)
--- free する ----------------+--------- free しない -------------
main main

..... ......
try { try {
funcA; funcA;
funcB; funcB;
..... ......
} catch { catch {
エラーメッセージ出力;exit(); エラーメッセージ出力;exit();
} }

static void funcA(void) { static void funcA(void) {
static XX *p1; static XX *p1;
static XX *p2; static XX *p2;

try {
p1=malloc p1=malloc
.... ......
if (エラー) throw if (エラー) throw
.... ....
p2=malloc p2=malloc
.... ....
if (エラー) throw if (エラー) throw
.... ....
if (p2) free(p2); if(p2) free(p2);
if (p1) free(p1); if(p1) free(p2);
} catch {
if (p1) free(p1);
if (p2) free(p2);
}
} }
#throw しているのはさらに1段下の関数かもしれない
------------------------------------------------------
(株) シーエーシー 大崎 貴之 ohs...@cacnet.cac.co.jp

[ohsaki takayuki]

おおさきです。

In article <20000616195...@nifty.ne.jp>, BXQ0...@nifty.ne.jp says...

>「受注生産の大規模な業務アプリ」かぁ。
>俺の井戸端のささやかな経験を加味した独断と偏見によれば(笑)、
>パッケージ入れて売られてるアプリや
>「世間に広く使われている(限定(^^;)」フリーソフトとか
>より、ナカミのデキという意味では「劣って」いることが
>多いんじゃねーかな、と思う。

総体的に見れば、おっしゃる通りです。 ^^;;;
しかし、他人のソースを読んだり、デバッグしなくちゃならない
立場から見ると、天才プログラマーが書いたフリーソフトなんか
でも、かなりスゴイ(どうしてこれでバグがでない？)ものがかなり
あります。

#「平凡な、スキルの低いプログラマを集めても、それなりの物を作る。」
#という点では、それなりのノウハウもあるんですが :-)

[oka...@cs.ehime-u.ac.jp]

岡久です。

<1312.96...@rananim.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。

>> 違うのは OS なんじゃないかなぁ。このあたりを library level で
>> 処理しているとは考えづらいです。そうだとしたら、なんか怖いし。

私も、あれれと思ったのですが、同じ環境で実行したもの
なんです。で、改めてチェックして見ると、VC++ 6 では、確
保された領域が全て同じ値でクリアされているようなんです。
calloc にあたる動作をしているのかもしれません。

>> それは、そうだよね。free() するのは、その必要がある時です。
>> 僕は割りとそんな感じ。普通のアプリケーションだと滅多に使わな
>> いんじゃないかな。もちろん、勝手にnew/destroyしまくる C++ で
>> はそうはいきませんが。

あと、あまりメモリを消費しない場合はマルチプロセスとま
で行かなくとも、再帰で書くと malloc 使わなくて済む場合も
ありますね。

# 余談ながら、VC++ 6 のヘルプの HeapDestroy の C++ に関す
# る記述は私の記憶間違いでした。別の書籍の記述とマージさ
# ていたようです。単に HeapDestroy で一挙に解放できると書
# いてありました。

--
Email: oka...@cs.ehime-u.ac.jp

[Hiroyuki Minesita]

From article <1916.96...@rananim.ie.u-ryukyu.ac.jp>
by ko...@ie.u-ryukyu.ac.jp

> >＃でも、「絶対にfreeが必要」って言うようなプロジェクト
> >＃では、malloc/freeの関数は使わないのも事実……(^^;

> おぉ! どんなものを使うのでしょう。I-TRON では free が必要って
> 話がありましたよね。

　すみません、また誤解を与えてしまいました。(__)
　malloc/freeを使わないのは業務の部分を作成する人たちで、
別の所でプロジェクト共通のライブラリとしてメモリ確保開放
の関数が作られるのでそちらを使う、と言う意味程度のもので
す。
＃Windowsだと大元はGlobalAllocなんでしょうけど……(^^;

＃ガーベージコレクションの機能を作り込んでいるらしい話が
＃あっても、やっぱり開放の関数は必ず使わないといけない……

[Kazuo Fox Dohzono]

堂園です.

In article <20000616200...@nifty.ne.jp>
BXQ0...@nifty.ne.jp (Nakamura Akifumi) writes:

> やっぱり受注のほうがパッケージやフリーみたいな
> 対外配布(?)ソフトより「アマイ」のかな。

そんなことないです. うちも受注ですが, 悪くするとバグで人が死にます.

--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp

[12],(6,9),0,0,2

[kuroda]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message news:8idol8$8t9$1...@nwms2.odn.ne.jp...
> > Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message news:8ici8i$adh$1...@nwms2.odn.ne.jp...
> > > > > > 　じゃ、必ずfreeする人がそれを新人に教えても構いませんよね。
> > > > > 教え方に問題があります。
> > > > > 「どんな時もexitの前で必ずfreeしなければならない。」
> > > > > は駄目です。
> > > それ以上に一般化する人はもっと駄目な人ですね。
> > 「allocしたら必ずfreeしなければならない。
> > ただしexitの直前ならfreeしなくていい。」
> > と言うべきなのでしょうか？
>
> 「一部の例外を除いて、allocしたらfreeした方がよい、もしくは、
> するように心がけよう」

なるほど。

＃ 『「どんな時もexitの前で必ずfreeしなければならない。」は駄目です。』
＃ 『それ以上に一般化する人はもっと駄目』
＃ 駄目な方法や言い方を駄目だというだけではなくて、
＃ このように「駄目じゃない」方法や言い方を示してくれると
＃ 私のようなものには理解しやすいです。

----蛇足----
でも私の感覚では
「一部の例外を除いて、…した方がよい」は緩すぎる気もする。
「一部の例外を除いて、allocしたらfreeすべき」や
「allocしたらfreeした方がよい」や
「allocしたらfreeするよう心がけよう」では駄目ですか？

--
----
■■ 黒田たかき
■■ kur...@sdl.hitachi.co.jp

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8ijvv1$n4l$1...@sunny.njk.co.jp> の
記事において 2000年06月19日(月) 02時19分13秒頃、
Hiroyuki Minesitaさんは書きました。

>> おいおい。それが「現場」なんすか？
>　かなり限定された話ですから……

あっそう。

>　もう一寸一般的な感覚とすると、実行ファイル中に
>５０の関数が有ったとしてその１つか２つだけを貰っ
>て作成する、と言うイメージになると思います。

ま、死人をつぎはぎして生者を作るのは大変でしょうからね。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <1143.96...@rananim.ie.u-ryukyu.ac.jp> の
記事において 2000年06月18日(日) 16時48分50秒頃、
Shinji KONOさんは書きました。

>>2. OS のレイヤーがちゃんと閉じていない可能性がある。
>
>こっちは、アプリケーションプログラマに関しては、知ったこっちゃなくて、
>もし、運悪くそういうOS上でアプリケーションを作ることになったら、
>
> そういうOSのバグに対処するレイヤ/コードを自前で付け加える
>
>ってのが普通じゃないかな。例えば、vi なんかは vi -r があって、
>Persistency という意味では不完全な Unix のプロセス/ファイル
>の連係をカバーしているわけですよね。

そういうレイヤ/コードを呼んでもらえるような仕込み
が可能であるかどうか？は、環境つーか状況に依存する
と思っていいですか？ですよね？

＃不可能な状況は、物凄くいやだなあ。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8ijt86$lip$1...@sunny.njk.co.jp> の
記事において 2000年06月19日(月) 01時32分54秒頃、
Hiroyuki Minesitaさんは書きました。

>　結局、状況次第で最善のやり方は変わるものだと言いたかっ
>ただけなのですが、極端に走ってしまった様です。

「なぜそれが(そのケースにおいてさえ)最善と
言えるの？」っていう話だったのでわ？

>　考えてみると、このニュースグループはＣ／Ｃ＋＋の言語
>自体を「目的」にした考え方語るべきで、「手段」でしかな
>い考え方を持ち出す方がどうかしていたのかも知れない、と
>思っている最中です。(^^;

それはあまり懸念する必要がないのでは？

「Cが目的」な人だとMinesitaさんが見こんでいる人(笑)も、
どうせmakeして実行するんだから、Cが手段(つーか道具)に
なる「瞬間」があるわけで。

一方、道具であるところのC言語の側は、アナタが
どんな心構えでその道具たるCを使っているかに「依存せず」
自分に為された仕打ち(笑)に対して正直な答えを返すだけです。

結局、我々(笑)全員の対象は、同じモノでしかないような。
「対象が違うのね」なんて言葉(=逃げ)は、どうせ
人間には通じてもCには(笑)通じませんから
考えるだけ無駄ですよねきっと。

＃自称現場の人は所謂研究者を…以下略…流石に飽きた。

>　「必要なfreeをしていないバグの検出が遅れる」とか、
>「無くてもいいfreeでも無いと問題にされる」とか、そんな
>所です。

後者は論外ですよね。
「問題にする」の主語は「計算機が」じゃなくて「人が」ですね？
ならば、徹底的にどうでもいい話なんで。

前者。必要なfreeってどうやって検出するんだろう？
必要かどうかを(OOPとかならさておき)どうやって峻別するんだろ？
＃思い起こせないのはやっぱり俺脳が従来からのボケと光化学スモッグと
＃馬鹿の喫煙によってイカレているせいかな？

>＃でも、「絶対にfreeが必要」って言うようなプロジェクト
>＃では、malloc/freeの関数は使わないのも事実……(^^;

ん？まず日本語として意味がよぉ取れぬ。
必要っていってるのに使わないとはこれいかに？

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8iej7e$t3r$1...@newsjp.mbn.or.jp> の
記事において 2000年06月17日(土) 09時51分09秒頃、
電子のお針箱 <ueno-...@di.mbn.or.jp>さんは書きました。

> でも、「強制終了などの特殊な場合にできないから、アプリケーションのレイヤー
>で確保/解放を閉じることは無駄である」と言うのは、「時速150Kmでぶつかったら、
>シートベルトなんて役に立たないから、シートベルトは役に立たない。」と言うのと
>同じ様な気がします。
>

># レイヤーで閉じることによる、メリット/デメリットの話をしましょうよ。

っていうか、話が「逆」になっていませんかそれ？

ここでは、解放をしてくれるプロセスなる仕組み「が」シートベルトである
わけですよね。プロセスの仕組みがアテにならない状況(仕組みを提供する
OS側の都合だったり、提供されるリソース側の云々だったり)における
アプリ側の手作業コードのほう「が」シートベルトである、と
お針箱さんは認識しているように、上記引用は読めるんですが、気のせい？

＃ゆっくり走ろう北海道

それはさておき、

> ある種の開発環境ではアプリケーションの終了時に、解放していないメモリーを表
>示する機能を持っています。レイヤーで閉じておかないと意図しない解放忘れと、意

>図的な解放省略が混在してしまいますよね。意図的な解放省略が少ない様な小規模ア
>プリケーションなら人手で判断することもできますが、大規模アプリケーションや複
>数人で共同開発している場合ではなかなか難しいと思っています。

別の面(笑)では、これは正しいように思います。
Cなんか使うな、という(笑)

ただ、そういうツールがある、という背景は、ここではどうでもいい
ような気がします。少なくともそれ「を理由に」すれば、主客転倒でしょうね。

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <1312.96...@rananim.ie.u-ryukyu.ac.jp> の
記事において 2000年06月18日(日) 18時17分41秒頃、
Shinji KONOさんは書きました。

>違うのは OS なんじゃないかなぁ。このあたりを library level で
>処理しているとは考えづらいです。そうだとしたら、なんか怖いし。

そういや今月(?)のBSD Magazineには、OS上で(仮想)メモリを
どんな風に管理してるか？の話が、いっぱい書いていますですね。ほへ。

>それは、そうだよね。free() するのは、その必要がある時です。
>僕は割りとそんな感じ。普通のアプリケーションだと滅多に使わな
>いんじゃないかな。もちろん、勝手にnew/destroyしまくる C++ で

＃「普通」って言うの、やめようよー

[Narita Takaoki]

成田です。

Nakamura Akifumi <BXQ0...@nifty.ne.jp> wrote in message news:20000616200...@nifty.ne.jp...
> 中村っす。うーいらいら。
：
> やっぱり受注のほうがパッケージやフリーみたいな
> 対外配布(?)ソフトより「アマイ」のかな。

いつもみんなが言っている、「一般化は止めよう」じゃない？全ての
受注生産がそういうわけでもない。

# 一般化すると、玉虫色の結論になる。(^^;;;

> ところで、全然知らないけど、例えば飛行機のシステムが
> こんなノリで作られてたりしたら、いやだなとは思います。
> 製鉄所とかも。他にも多数あるだろうな。

むしろ、どういう使い方するかある程度分かっていて、その上で責任
をもって作っているなら、少なくともパッケージで「このソフトを利用す
ることにより生じた損害に関しては云々」と書いてある代物に許諾し
ないとならないとして作っているのと比べてどうだろうか。

--
Narita Takaoki @A.I.SOFT,INC.
『いわば・・・札師に筆師！そしてちから技師・・・
といったカンジでしょーか！？』

[Nakamura Akifumi]

中村っす。

fj.comp.lang.c,fj.comp.lang.c++ の <8ikuta$l51$1...@epsongw6.epson.co.jp> の
記事において 2000年06月19日(月) 20時10分28秒頃、
"Narita Takaoki" <tak...@aisoft.co.jp>さんは書きました。

>> やっぱり受注のほうがパッケージやフリーみたいな
>> 対外配布(?)ソフトより「アマイ」のかな。
>
>いつもみんなが言っている、「一般化は止めよう」じゃない？全ての
>受注生産がそういうわけでもない。

ええ。んだから、一般化してくれちゃった人(笑)が既にいたので。

>むしろ、どういう使い方するかある程度分かっていて、その上で責任
>をもって作っているなら、少なくともパッケージで「このソフトを利用す
>ることにより生じた損害に関しては云々」と書いてある代物に許諾し
>ないとならないとして作っているのと比べてどうだろうか。

そういや、「製鉄所ではそうは書けない」かどうかは
俺は知らないなあ。しまった。

[Kazuya Maebashi]

前橋です。

電子のお針箱 wrote in message <8ii9bm$rmb$1...@newsjp.mbn.or.jp>...
>Shinji KONO <ko...@ie.u-ryukyu.ac.jp> wrote in message
>news:28572.9...@rananim.ie.u-ryukyu.ac.jp...
...
>1. アプリケーションレイヤーで閉じることにより、一部の処理系で意図
> しない解放忘れを検出しやすくなる。

これは賛成します。

それなりに長時間実行してみて、終了時に、全ての領域が開放されてると、
安心できますよね。VC++はちょっとしか使ったことはないですが、開放忘れの
領域の一覧を出してくれる機能は、便利だと思いました。

exit()前のfree()は、要るか要らんかといえば *不要* だと思いますが、
たとえムダな作業だとしても、それでバグを潰せるならおおいに結構だと
思います。

もちろん、問題になるほど遅くなったら、その時は対処するとして。

それから、以前に電子のお針箱さんがおっしゃっていたように、
あとでライブラリとして使いまわすかもしれないからちゃんと開放して
おこう、というポリシーも理解できます。

ただし、

>2. OS のレイヤーがちゃんと閉じていない可能性がある。(Windows の
> 一部のリソースで。また、Unix の一部の実装でメモリーリークがあっ
> たこともあります。なお、商用システムでは、OS を一週間に一度リブー
> トするような構成を取ることもあります。)
>
>と言う理由からです。(要は、階層化されていレイヤーでは各階層で
>ちゃんと閉じていることが必要でしょうということです。下位層で漏れて
>いるリソースはその上の層で回収されると思われますが、それを期待
>することはあまり望ましくないと思います。)

こっちは賛成しませんが。

期待できるものに期待してもいいと思うし、移植の可能性もないような
チープな環境なんぞ考慮してもしょうがないです。

> 私は、全ての環境で必ず exit() 前に free() しろなんて言っていません。ある
特
>定環境では、exit() 前に free() しないことの方が望ましい状況があるかと思いま
>す。ただ、私の周りの環境では、exit() 前に free() した方が望ましいと言うだけ
>のことです。

小さな使い捨てプログラムなら、malloc()だけしてfree()なんぞ全くしない
プログラムだってあり得るし、

exit()直前までfree()しないデータ構造ってのは、「設定ファイルを読みこんで
メモリ上に展開する」ってのが多いから、既に何人もの人が挙げておられるように、
「まとめてメモリを確保して小分けして渡してくれる関数」でも書いて、
最後にまとめて開放するもよし、

あるコマンドを実行するのに必要な一時作業領域、ということなら、
その領域を別管理してコマンド終了後にまとめて破棄してもいい。
ただし、ループの中で確保/開放を繰り返してたりすると、これはちょっと
危険。

そいで、強制終了の場合には、OSがちゃんと回収してくれるでしょう。
何も問題なし。

結局、こういうのはケースバイケースなので、みなさんおっしゃるように、
「過度の一般化は避けよう」に尽きるように思いますね。

「このプロジェクトでは、開放忘れをツールで検出するんだから、
exit()まで残る領域でもちゃんと開放しておけ」

ならわかりますが、

「malloc()とfree()は常に対で使うべきだ」

とか、

「初心者にはmalloc()したら必ずfree()しろと教えるべきだ」

というのは、どうも変だと思いますね。

どんなに末端のプログラマでも、コーディングするんなら、ワーカーじゃなくて
エンジニアだろうと私は思います。

# もちろんお寒い現実はいくらでもありますよ ←予防線

# 私自身がそのレベルに達しているかという話も置いといて (^^;;

いくらペーペーでも、理由も考えさせず規則に従わせる、ってのは、
望ましくないと私は思います。

# 実装まで知らなければいけないといっているわけではありません。
## でも、大抵の場合、実装から攻めたほうが理解が早い。ちょっと
## 危険だとは思いますが。

どうも、この辺に、「電子のお針箱」さんとの認識のズレがありそうな気が
しますです。

------------------------------------------------------------
前橋 和弥 maeb...@cse.co.jp
http://member.nifty.ne.jp/maebashi/
------------------------------------------------------------

[okabe katsuyuki]

岡部です。

"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:

> > > ＶＣ＋＋のｍａｌｌｏｃ（）を見てみました
> > > どこにも
> > >
> > > ｈｅａｐから確保します
> > >
> > > とは書いて無かったです
> > > ＃Ｃ言語の規格書にはそう書いてあるのかな？
> > >
> > > 書いてないことを期待してはいけません
> > > ＃まあｈｅａｐから確保するんだろうが
> >
> > VC++6のfree()には「OSに返す」とも書いてありませんよね
> > それじゃどこに返すの？
>
> 私はＯＳから確保してＯＳへ返すとは一切言ってないです
> ＯＳとかを引っ張り出してくるのはｅｘｉｔ（）前はｆｒｅｅ（）しなくても良い
> っていってる人たちです
> ＃ｈｅｒｐから確保されるから大丈夫。。とかね
>
> 私は
>
> ｍａｌｌｏｃ（）はあるメモリブロックから指定されたサイズのメモリを
> 割り当てる関数で、ｆｒｅｅ（）は確保したメモリをメモリブロックへ
> 返却される
>
> と理解してます
>
> メモリブロックは「「　抽象化　」」しているので、
> それがｈｅａｐメモリだろうとグローバルメモリだろうと
> 実装がどうなってるかなど知ったことではありません
> ＃逆にいえば、どのように実装されていても良いということです

「ＶＣ＋＋のｍａｌｌｏｃ（）を見てみました」と書かれていたのでVC++に限
定した話かと思ったのですが、そうではなかったのですか？
VC++に限定しないのであればANSI Cの規格を持ち出された方がよかったと思い
ます。

わたしのはあくまでVC++6に限定した話です。

[S.Masa]

S.Masa です．

"Nakamura Akifumi" wrote
about "Re: スレッド 「 Malloca ndFree 」 が読めない"
on Mon, 19 Jun 2000 17:51:02 +0900
Message-ID <20000619175...@nifty.ne.jp>

>>>　「必要なfreeをしていないバグの検出が遅れる」とか、
>>>「無くてもいいfreeでも無いと問題にされる」とか、そんな
>>>所です。
>>
>>後者は論外ですよね。
>>「問題にする」の主語は「計算機が」じゃなくて「人が」ですね？
>>ならば、徹底的にどうでもいい話なんで。
>>
>>前者。必要なfreeってどうやって検出するんだろう？

プログラム終了まで確保しておく必要のないメモリって事じゃないんですか？
exit() 前に free() は要らなくても，exit() 前じゃない場合は必要ですよね？
#違うかな？

2000/06/20(Tue) 09:47:32
--
Word by Ｓ．Ｍａｓａ
masa.s...@nifty.ne.jp
http://member.nifty.ne.jp/smasa/

[電子のお針箱]

Shinji KONO <ko...@ie.u-ryukyu.ac.jp> wrote in message

news:1143.96...@rananim.ie.u-ryukyu.ac.jp...

>> 河野さんは SIGKILL でもちゃんと終了処理できる Middle ware、ライブラリ や
>> アプリケーションを作れると言うのでしょうか ?

> もちろん、OS は、リソースリークしないように設計されるべきで、
> そうでないのはバグです。もし、リークしないアプリケーションが
> 書けないってことなら、それは仕様上のバグですよね。

で、河野さんは SIGKILL でもリークしない Middle ware、ライブラリ や アプリ
ケーションが書けるのですか ?

# 一般的な話を聞きたいわけではありません。

> > もちろん、そうです。軽視しているわけではありません。上記の様な強制終了

> > 時に破綻しないのはこれらのレイヤーでちゃんと保護されているからであること
> > は認識しています。ただ私がアプリケーションレイヤーにこだわるのは...
>
> それって、プロセスレイヤである spwan/fork/exit の話なのに、何故か、
> アプリケーションレイヤにこだわる話ですよね。それはおかしいんじゃな
> いですか? 二つの階層をごちゃごちゃにしているわけでしょう? 上位の階
> 層の解放が、下位の階層の解放を意味するのは、レイヤを構成するならば
> 必須ですよね。

ごっちゃにしているのは、河野さんの方ではないですか ? 上位の階層の解放が下
位の階層の解放を含むのは当然かと思いますが、だからと言って下位の階層がそれを
期待すべきではないですよね。(でないと、何のために階層化しているかわかりませ
んよね。)

> もし、この二つのレイヤーを完全にネストするならば、
>
> fork() した後に、malloc() でメモリを確保して memcpy() する

これって OS 側がやってませんか ? どっちかって言うと、exec() の方がネストに
反していると思います。

> exit() する前に free_all() する

河野さんは、解放をとにかく一度で行えば良いとお考えですか ? アプリケーショ
ン内でも、階層化したりすることはないのですか ?

> まで、するべきかも知れない。そうではなくて、static 領域とか code 領域
> とかを気にしないってことなら、単なる自己満足ですよね。そうではなくて、
> memcpy() するのは、無駄だと思うんだったら、exit()の前のfree()だって、
> 同じくらい無駄だと思う。

static/code 領域の確保/解放は OS の仕事であり、OS のレイヤーで閉じていま
す。アプリケーションは、これらの確保/解放には感知しません。

# 階層化についてちゃんと理解されていますか ?

> >1. アプリケーションレイヤーで閉じることにより、一部の処理系で意図しない解
> > 放忘れを検出しやすくなる。
>
> それって exit() の前のfree()とは関係ない。レイヤが違うんだから....

どう違うのですか ? 上の文については、アプリケーションレイヤーしか問題にし
ていませんよ。

> >2. OS のレイヤーがちゃんと閉じていない可能性がある。
>
> こっちは、アプリケーションプログラマに関しては、知ったこっちゃなくて、
> もし、運悪くそういうOS上でアプリケーションを作ることになったら、
>
> そういうOSのバグに対処するレイヤ/コードを自前で付け加える
>
> ってのが普通じゃないかな。例えば、vi なんかは vi -r があって、
> Persistency という意味では不完全な Unix のプロセス/ファイル
> の連係をカバーしているわけですよね。

そうですね。全てにおいて完全な OS と言うのは存在しないので、色々な方法でリ
カバーすると言うのは正しい姿勢だと思います。

> exit(),malloc(),free() を overwrite して、malloc()した領域を
> すべて管理する形にして、exit()の前にfree_all() してやれば良
> いんですよね? そんな形で形式的に簡単に満たせる「exit()の前の
> free()」に、なんの価値もないと僕は思うし、きっと箱氏もそう思
> うでしょ?

はい、形式的にやるのには何の価値もないですね。

> そうではなくて、malloc(), free() の対応が重要なんだってことなら、それは、

> アプリケーションレイヤでも、単純な対応にならない場合があるってのを付け加え
> ないといけません。そこに、exit() の前にfree() とかの教条的なルールが入る余
> 地はないと思う。

はい、色々な場合がありますから free() を対応付けるのが困難な場合もあると思
います。もちろん、そう言う場合には free() を省略して OS に任せると言うのが望
ましい場合もあるかと思います。ただ、私の周りの環境でそう言う場合と言うのはど
ちらかと言うと例外的な場合であると思っています。

> もし、malloc()/free() checker みたいなツールを作ったとして、
> (もちろん、完全なcheckは不可能なんだけど.. 限られたプログラ
> ムならできるかもしれない) 箱氏は、exit() の前に free() して
> ないっていう Warning を出すように作ることに意味があると思う
> の?

「このようなツールを使った時に、意図しない free() 忘れが exit() 前の
free() をしていないという Warning に隠れてしまうことを避ける為に、exit() 前
の free() 模しましょうよ。」と言うことです。

# この手のツールは使ったことないですか ?

--
--------------
電子のお針箱
ue...@di.mbn.or.jp
(From: ヘッダーはスパム対策のため -nospam を付加しています。)
--------------

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

news:8ii6gl$ncu$1...@nwms2.odn.ne.jp...

> > > > # レイヤーで閉じることによる、メリット/デメリットの話をしましょう
> > > > # よ。
> > >
> > > ここで議論している方は、メリットについては話すまでもなく知っ
> > > ているはずです。議論の余地はありません。一定レベル以上の人間
> > > にとっては情報量０です。
> >
> > 済みませんが、情報量 0 と思われましたら、読み飛ばしていただけません
> > か ? 鶴田さんは情報量 0 と感じられかも知れませんが、メールではありませ
> > んから鶴田さんにだけ配信されているわけでありません。
>
> それは私が判断することです。私は既に提示された事実を踏まえて、
> 議論を進めようとしているわけであって、それを止めろといわれる
> 理由はないと思います。

わかりました、私は今情報量のある/無しについて議論しているわけではありませ
んので、こちらで無視させていただきます。

> > > > ある種の開発環境ではアプリケーションの終了時に、解放していないメモ
> > > > リーを表示する機能を持っています。レイヤーで閉じておかないと意図しな
> > > > い解放忘れと、意図的な解放省略が混在してしまいますよね。意図的な解放
> > > > 省略が少ない様な小規模アプリケーションなら人手で判断することもできま
> > > > すが、大規模アプリケーションや複数人で共同開発している場合ではなかな
> > > > か難しいと思っています。
>
> > 確かに、私の主張中に「malloc() した領域が不要になったら (* 何も考えず
> > に *) free() すべきである」と言う記述があるかと思います。ただ、誤解して
> > 欲しくないのですが、これは 「free() する/しない」についてはとりあえず考
> > えないと言うことです。ここで、free() するとなったらその引数や実行場所に
> > ついてはちゃんと検討が必要なことは言うまでもありません。
>
> なるほど、あまり考えたくないのと、バグを面倒みてくれるツール
> に頼りたいからfreeしたいわけですね。それならＯＫです。確かに
> そのレベルのスキルの人にとってはfreeは必須かもしれません。

そうです。

# ツールをうまく使うのも、腕のうちですからね。

[電子のお針箱]

KATAYAMA Yoshio <ka...@pfu.co.jp> wrote in message
news:KATE.00Ju...@yamato.trad.pfu.co.jp...

> >> >> >「アプリケーションのレイヤ」で保証しないと、不許可を出され
> >> >> >ます。「ＯＳが保証するからしなくていい」なんてのは理由にな
> >> >> >らないのです。
>
> >> >> これを保証するためには、すべてのシグナルを拾って、シグナルによる
> >> >> 異常終了（強制終了）が起きないようにしなければなりません。また、
>
> >> 端末割り込み（これは拾えるから問題ないか）や強制終了はバグとは関
> >> 係ないですね。つまり「『アプリケーションのレイヤ』で保証」できな
> >> いわけです。それを「保証する」と言うのが現場というわけでしょうか。
>
> > 強制終了等の場合はしょうがないですね。(と言うより、それをアプリケーショ
> > ンがトラップできたら終了しないアプリケーションが作れてしまいますか
> > ら...。)
>
> 「しょうがないですね」で済むのを「保証する」と言うのですか。お気
> 楽な「現場」ですね。

通常の場合と、例外的な場合は区別なさらない ?

# 通常の走行である、時速60km での衝突では身体の安全性を保障しますが、時速
# 150km 等の無謀な走行状態での安全性を保障するものではありません...。普通
# の製品は大体そうですよね。

> > でも、「強制終了などの特殊な場合にできないから、アプリケーションのレイ
> >ヤーで確保/解放を閉じることは無駄である」と言うのは、「時速150Kmでぶつ

> >かったら、シートベルトなんて役に立たないから、シートベルトは役に立たな

> >い。」と言うのと同じ様な気がします。
>
> 「強制終了などの保証できない場合もあるのに『保証する』と言えるの
> か」と聞いているのです。「シートベルトをしていたら、時速150Kmで
> ぶつかっても身体の安全を保証します」と言えるのかということです。

答えとしては、「シートベルトだけで時速150kmでの衝突において身体の安全を確
保することは困難である。」でしょうね。

そう言う状態を保証しないといけないのであるならシートベルトだけで対処するの
は現実的ではありませんね。もっと別のアプローチを採用するべきでしょう。

# そのアプリケーションが想定している一般的な状態と言うもので考えています。も
# し、特殊な場合を想定して議論するのであれば、その特殊な状態をちゃんと規定し
# ないと不毛な議論になると思います。

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message

news:8iidpj$5t9$1...@nwms2.odn.ne.jp...

> > > > > > ある関数がちゃんと動作しない原因を調べることもできないほど切羽
> > > > > > 詰った状況が望ましくないのは確かですし、そう言う状況にならないよ
> > > > > > うにしようと努力/議論することは大切なことですが、それと今現在そ
> > > > > > う言う状況が存在することと別ですよね。
> > > > >
> > > > > 「善し悪し」というのは、既に「存在」を認めているのです。
> > > >
> > > > これは、正しいです。(存在を否定したことはありませんよ。)
> > >
> > > それはそうでしょう。電子のお針箱さんの立場で否定したら、議論
> > > から退場ですってば。(^^;
> > >
> > > ただ、既に認めているものに対して事実という反論をされるのは、
> > > まるで当方が存在を否定しているかのようにみられるので、それが
> > > 困るのです。
> >
> > 私は、鶴田さんが存在を否定していると言うような発言はしていないつもりで
> > す。表現上問題がある個所があるかもしれませんので、そう感じられた記事を指
> > 摘していただけますか ?
>
> 既にまとめてありますが。
> Message-ID: <8i8ldp$if1$1...@nwms2.odn.ne.jp>

ああ、あのわけわかの投稿ですね。失礼ですが投稿の意図が不明ですし、各々の投
稿には既にフォローがつけてあると書いてあるはずですが...。

> > > > > そこに「存在」を主張しても、何の情報も提供していないことは理
> > > > > 解出来ますよね？
> > > >
> > > > これが変。「なぜりんごが落ちるのかなぁ ?」「万有引力があるからだ
> > > > よ。」この場合も、単に存在を主張しているだけですが情報量は 0 です
> > > > か ?
> > >
> > > 例に合わせるなら、万有引力を既に全員知っているから、情報量０
> > > なんです。存在を知らない人相手に主張するのならともかく、存在
> > > を認めている相手にわざわざおっしゃるのは、馬鹿にしているのか
> > > と思えるほどです。
> >
> > そう言われるのであれば...
> >
> > 1. 万有引力とりんごが落ちることと関係を知らなかった...
> >
> > --> ああなる程、りんごが落ちるのは万有引力のせいかぁ。よくわかったよ。
> >
> > 2. 万有引力とりんごが落ちることとの関係を既に知っていた...
> >
> > --> そうだよねぇ。なぜ「りんごがなぜ落ちるか」なんて質問したんだろ
> > う...。
>
> そういう質問が問題じゃないので、このアナロジーは不適切。

はぁ、そうですかと言うしかないです。

> > の二つの答えしかないでしょう。それに対して、「万有引力なんて当たり前ジャ
> > ン。当たり前のことなんか論拠にならないよ。」と言われているのですよ。
> >
> > # どうすりゃ良いのでしょうか ? 別の論拠を考えて良いのですけど、同じ論理
> > # でやられそうな気がするし...。
>
> だから、事実に関することは既に終わっているんです。繰り返す必
> 要無し。

そうですか ? 私とは、議論しているものが違うわけですよね。

> > > > 私は、自分の主張の根拠として事実を挙げているのです。その事実の存在

> > > > の有無を問題にしているわけではありません。わたしの主張と異なる方が、
> > > > これらの存在を知らないのかわたしの主張との関連を見出せないのではない
> > > > かと言うことで、例としてあげているのです。
> > >
> > > だから、その事実に対して、議論がされているんですよ。
> >
> > 事実の何について議論しようとしているが、明確にしていただけませんか ?
>
> 善し悪し。

すみません、私はその様な (* わかりきった *) ことに対して議論しているわけで
はありませんので、抜けさせていただきます。

> > # 私は、その事実自体については論拠として提示しているだけであって、議論し
> > # ているわけではありません。
>
> 何の論拠として事実を挙げておられるのですか？

すぐ下に書いてある「理由を知らないで関数を使わないことがある」と言う主張の
根拠です。(何回か書いてますが...。)

> > > 「その事実の存在の有無を問題にしているわけではありません」は、
> > > 当方の主張です。あげられた事実はありふれた話で議論の余地はあ
> > > りません。
> >
> > 私も、鶴田さんも「存在の有無については、その事実は存在している」と言う
> > ことで一致していることはご同意いただけていると思います。その上で、私はそ
> > う言う事実をわたしの「理由を知らないで関数を使わないことがある」という主
> > 張の論拠としています。
>
> 「理由を知らないで関数を使わないことがある」が主張なら事実はなんですか。
> 「理由を知らないで関数を使わないことがある」が事実なら主張はなんですか。

「理由を知らないで関数を使わないことがある」と言う事実があると言うことを主
張しています。

> 以下の空欄を埋めよ。
>
> 　主張：
「理由を知らないで関数を使わないことがある」と言う事実があると言うこと

> 　事実：
上記主張が存在すること

> で、私は、「使うなといわれただけで、理由を知らないで関数を使
> わないことがある」態度は良くないと申し上げているのです。
> # ただし、これは、scanfについてであることに注意。

はい、これには反対していません。(それこそ、情報量 0 でしょ。)

> > > > > 「存在」の上で「善悪」は成り立つが、「善悪」の上に「存在」があるの
> > > > > ではないのです。
> > > >
> > > > わたしのどこの主張から、こう言う解釈を導かれたのでしょうか ? 書き
> > > > 方がまずいかもしれないので、よろしければ教えていただけますか。
> > >
> > > 「善し悪し」の議論に対し、「事実」という反論をされたからです。
> > > そこでは事実など必要ありません。
> >
> > 良し悪しの議論については、岡久さん側からの反論です。私は、「良し悪しな
> > んか関係ありません、事実として存在している」と言うことを論拠にしているだ
> > けです。
>
> 「事実として存在している」と言うことを論拠に何を主張している
> のですか？単に駄目な奴がいっぱいいるっていいたいだけ？

世の中いろんなケースがあるから、「使わない関数の使わない理由を必ず知らなけ
ればならないと言うことはない」と言うことです。

# まあ、これだって情報量 0 ですけどね。(でも、間違ったことに対する反論って大
# 体そうではないのでしょうか ?)

[電子のお針箱]

ohsaki takayuki <ohs...@cac.co.jp> wrote in message
news:8ijt42$6...@infonet.sedept.cac.co.jp...

> > 私は、全ての環境で必ず exit() 前に free() しろなんて言っていません。

> > ある特定環境では、exit() 前に free() しないことの方が望ましい状況がある
> > かと思います。ただ、私の周りの環境では、exit() 前に free() した方が望ま

> > しいと言うだけのことです。
>
> 私も「malloc したら必ずfree」 と言っていますが
> #「free 忘れ」には結構悩まされてますので :-)
>
> しかし、exit 時には free しない形としてます。
> その理由は、余分なコード(バグの元)が必要になるからです。
> #決して、特定環境ではありません :-)

例外処理時には、free() しないと言うことですね。その意見自体には同意できる
ところもあります。ですが...

と言うのは、ちょっとまずいのではないですか ? funcA() で exit() しないのであ
れば、funcA() から抜ける時は、(* たとえそれが例外時でも *) ちゃんと free()
する様に作るべきでしょう。

1. 何らかの変更で、上位プログラムが funcA() の例外時に exit() しなくなるかも
しれません。(仕様が変わってリトライするようになるかもしれません、その時
funcA() のリークに気づきますか ? 上位を変更するのが他人や１年後の自分かも
しれませんよ。)

2. いちいち free() する為には、コード量が増えますからバグの確率も増えるわけ
です。でも、free() しないからと言ってバグがなくなるわけではないですよね。
(その証拠に、free() しない版の方に...

if(p1) free(p2);

と言うバグがあります。(^_^))

また、C++ なら malloc()/free() でなく new/delete を使った方が良いと思いま
す。

class XXX {
public:
XX *p;
XXX(){
p = new XX;
}
~XXX(){
delete p;
}
}

static void funcA(void)
{
try {
XXX p1;
...
if(エラー) throw
...
XXX p2;
...
if(エラー) throw
...
}
}

と言う感じでどうですか ?

[Shiro SADO]

exit()直前にfree()しなければならないかどうかの問題とは別に、

スレッド「Re: スレッド 「Malloc and Free」 が読めない」での
ueno-...@di.mbn.or.jp氏の発言 <8inqrb$dcm$2...@newsjp.mbn.or.jp> より引用

>> 「このようなツールを使った時に、意図しない free() 忘れが exit() 前の
>> free() をしていないという Warning に隠れてしまうことを避ける為に、exit() 前

>> の free() もしましょうよ。」と言うことです。

それでは道具に使われてしまってません？

このようなツールを使う時は、意図しない free() 忘れが exit() 前の
free() をしていないという Warning に隠れてしまうことを避ける為に、
exit() 前の free() もしろ

ということならわかるのですが……。
# まだ使いもしない道具を想定して、って変ではないです？

スレッド「Re: スレッド 「Malloc and Free」 が読めない」での
ueno-...@di.mbn.or.jp氏の発言 <8inqr8$dcm$1...@newsjp.mbn.or.jp> より引用
>> # ツールをうまく使うのも、腕のうちですからね。

---
佐渡詩郎 (さど しろう) / e-mail : sa...@smlab.tutkie.tut.ac.jp

[Daishi MORI]

もりです。本題とは関係ないです。

On 18 Jun 2000 18:17:41 GMT,
"河野" == Shinji KONO <ko...@ie.u-ryukyu.ac.jp> writes:

河野> In article <8iiu4s$qra$1...@csgw2.cs.ehime-u.ac.jp> ,
河野> oka...@cs.ehime-u.ac.jp writes
>> これなのですが、VC++ 6 と Borland C++ 5.5 では挙動が
>> 異ります。Borland C++ 5.5 では実際にメモリへの代入等が
>> あった時に始めて実メモリが消費されるようですが、VC++ 6
>> では始めから消費されます。デバッグモードやオプションの
>> 有無で変わる可能性はありますね。

河野> 違うのは OS なんじゃないかなぁ。このあたりを library level で
河野> 処理しているとは考えづらいです。そうだとしたら、なんか怖いし。

# さすがに OS が違うって事は無いと思いますが…。
# どっちも Windows 用のコンパイラですよね?

おそらく Win32 の VirtualAlloc() 関連の API を使ってるんじゃないでしょ
うか。

これを使うと、一旦アドレス空間の一部を予約しておいて、そこに後から必要
な分だけページを割り当てる(MS はこれを「コミットする」と呼んでます) 事
が出来ます。もちろん、予約と同時にコミットする事も可能です。

詳しくは覚えていませんが、岡久さんが仰るように demand paging するよう
な指定も可能ではなかったかと思います。

実際に paging するのは OS ですが、いつ paging するかをアプリケーション
レベルである程度制御できちゃうんです。なので、そういう意味では library
level で処理しているといっても過言ではないでしょう。

# GUARDED PAGE なんて指定も出来たような…。

--
もり <mor...@qc4.so-net.ne.jp>

[oka...@cs.ehime-u.ac.jp]

鶴田さんこんばんわ、岡久です。

今回の議論ではいろいろとありがとうございます。

ねばっていた私が言うのもなんですが、ひょっとしたら、もう
そっとしておく時が来たのかもしれません。

というのも、ここしばらく激論が交わされたあと、しばらくの
空白があったからです。当事者が皆 100% 納得したということは
ないでしょうが、それでも大多数の人は十分に語り尽くしたと感
じたのではないでしょうか?

# お互い、よくやったと言うことで...

--
Email: oka...@cs.ehime-u.ac.jp

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <86hfape...@qc4.so-net.ne.jp> ,
Daishi MORI <mor...@qc4.so-net.ne.jp> writes
># さすがに OS が違うって事は無いと思いますが…。

うん。OS が同じでも、ライブラリが malloc で zero clear する
ってことなら違うのは納得できます。malloc で zero clear は、
普通は反則だよね。

>これを使うと、一旦アドレス空間の一部を予約しておいて、そこに後から必要
>な分だけページを割り当てる(MS はこれを「コミットする」と呼んでます) 事
>が出来ます。もちろん、予約と同時にコミットする事も可能です。

おお、なんか便利そう。mmap の親戚みたいなもんだな。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> ああ、あのわけわかの投稿ですね。失礼ですが投稿の意図が不明ですし、各々の投
> 稿には既にフォローがつけてあると書いてあるはずですが...。

どおりで、君には理解出来ないはずだ。ようやくわかりました。

> そうですか ? 私とは、議論しているものが違うわけですよね。

君がしているのは、議論じゃなくて、ただの主張。プロパガンダ。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> > > > > 私は、自分の主張の根拠として事実を挙げているのです。その事実の存在
> > > > > の有無を問題にしているわけではありません。わたしの主張と異なる方が、
> > > > > これらの存在を知らないのかわたしの主張との関連を見出せないのではない
> > > > > かと言うことで、例としてあげているのです。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> > > # 私は、その事実自体については論拠として提示しているだけであって、議論し
> > > # ているわけではありません。
> >
> > 何の論拠として事実を挙げておられるのですか？
>
> すぐ下に書いてある「理由を知らないで関数を使わないことがある」と言う主張の
> 根拠です。(何回か書いてますが...。)

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> > > 私も、鶴田さんも「存在の有無については、その事実は存在している」と言う
> > > ことで一致していることはご同意いただけていると思います。その上で、私はそ
> > > う言う事実をわたしの「理由を知らないで関数を使わないことがある」という主
> > > 張の論拠としています。
> >
> > 「理由を知らないで関数を使わないことがある」が主張なら事実はなんですか。
> > 「理由を知らないで関数を使わないことがある」が事実なら主張はなんですか。
>
> 「理由を知らないで関数を使わないことがある」と言う事実があると言うことを主
> 張しています。
>
> > 以下の空欄を埋めよ。
> >
> > 　主張：
> 「理由を知らないで関数を使わないことがある」と言う事実があると言うこと
>
> > 　事実：
> 上記主張が存在すること

こんなことを平然と言えるとはすごいですね。恥ずかしくないので
しょうか。

上記defineを展開すると以下の文章は、次のように置換される。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> 私は、自分の主張の根拠として事実を挙げているのです。

↓

私は、「理由を知らないで関数を使わないことがある」と言う事実
があると言うことの根拠として「理由を知らないで関数を使わない
ことがある」と言う事実があると言う主張が存在することを挙げて
いるのです。

# 爆笑。
____________________________________________________________
Name : Shin-ichi TSURUTA 鶴田 真一 (as SYN)
E-mail : syn...@pop21.odn.ne.jp
URL : http://www1.odn.ne.jp/synsyr/

[KATAYAMA Yoshio]

In article <8inqre$dcm$4...@newsjp.mbn.or.jp>,電子のお針箱<ueno-...@di.mbn.or.jp> writes:

> 通常の場合と、例外的な場合は区別なさらない ?

># 通常の走行である、時速60km での衝突では身体の安全性を保障しますが、時速
># 150km 等の無謀な走行状態での安全性を保障するものではありません...。普通
># の製品は大体そうですよね。

またまた、お得意のスレッドを無視したスリカエですか、、、
--
片山＠ＰＦＵ

[KATAYAMA Yoshio]

In article <5545.96...@rananim.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

>うん。OS が同じでも、ライブラリが malloc で zero clear する
>ってことなら違うのは納得できます。malloc で zero clear は、
>普通は反則だよね。

indeterminate であって random ではありませんから、反則（って何だ？）
ではないでしょう。遅くなるからやらないだけでしょう。
--
片山＠ＰＦＵ

[Hoshi Takanori]

ほし＠えすあーるえーです。

＃ わたしもぜんぜん納得してません。馬鹿らしくなって
＃ 抜けただけ。

In article <27482.9...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

> なるべく早く終了する。

伝統的な UNIX プログラムだとこれが当たり前なんだけど、
それが通用しない環境もあって、かつ、最近ではそっちの方が
『めぢゃ～』なんだよね。困ったことに。

なので、とりあえず最初に、
malloc() したら必らず free() してね。
と教えて、あとで、「実は...」とやるわけ。いけない？

> あるいは、その手のプログラムを、モジュールなどで閉じ込めて、
> モジュール内専用の(freeしない)malloc を使うとか。

そのモジュールが、一つの仕事をしたらさっさと抜けてくれて、
あとはその中で malloc() したものを全部まとめて free() できる
ならいいんだけどね。最近ではそうもいかんのですよ。

ほし

[Hoshi Takanori]

ほし＠えすあーるえーです。

＃ 昨日まで新人研修のヘルパーをやってました。

In article <8idol8$8t9$1...@nwms2.odn.ne.jp>
Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> writes:

> 「必ず」と言うのは、非常に危険な修飾語ですよ。

新人には、「必らず９時までに出勤しなさい。」と教えてました。
自分は毎日のように遅刻してたけど。(笑)

Java API ドキュメントみたいに、詳細な説明がいっぱいあると、
かえって何が何だか分からなくなるみたいだし。

世の中ってそおゆうものでしょう。

> # 新人が自ら「おかしい」とか、「特殊な場合出会った」と感じる
> # 瞬間を摘み取ってはならないと思います。

「必らず」と書いてあろうがなかろうが、おかしいと思ったら
聞いてきますって。(ひとりで考え込む人もいるけど...)

その時にちゃんとフォローすればいいんです。

ほし