>>951 >ガーベージコレクションなんて
>不要です。本来メモリー管理はプログラマーの責任です。
この一文で読む気なくした
オブジェクト指向を理解できないと、会社が潰れる罠
おれは全く関係ないがな
>>952 やさしいんだな。
俺は怒りに震えたぞ。
957 ：
仕様書無しさん：03/12/07 16:50
>>952 ガベコレ無いと嫌な人って何やってプログラム組んでるの？
俺の場合newと対応したdeleteは必ず同じクラスに置くから。
単純な書き忘れならメモリリークの警告がでるし、ガベコレなんかなくてもこまらねーよ？
>>957 C++にはコンストラクタとデストラクタの
連携があるのでさほどGCを必要と感じないんでしょうね。
いちばんベストなのはオプショナルにGCの使用を選べる事だと思うのですが。
>>957 お前が難しいモデルを実装した経験がないだけ。
なんならガベコレ無しでしっかりメモリ管理ができる
Lisp を実装してみろ。
GCよりGCの間接的な利点である不正なメモリへの読み書きが
防げる方がもっと重要だよ。
ライブラリでエセGCを実現しているC++は不正なメモリへの
読み書きが出来てしまうからだめだね。
961 ：
仕様書無しさん：03/12/07 17:03
>>958-959 Windowsのソフトしか組んだこと無いからメモリ管理なんか気にしたことないんだけど。
少なくともあんまり特殊なソフトを作らない限りそんなものっていらないよね？
結局、メモリの管理もしてくれない駄目なＯＳがのってる環境だとガベコレが必要になるわけ？
>>961 お前、mallocって知っているか？ newって知っているか？
動的にメモリ確保すること知っているか？
ガベゴレをつくらなくてはいけないのは、ガベゴレがヘタクソにできあがっている
処理系とか、セグメントアクセスを考慮にいれなきゃいけないデバイスの作成とか
かね。 いまのところ必要ねぇけど。
964 ：
961=957：03/12/07 17:10
>>962 いえ、ですから、newでクラス作ってdeleteで消すだけですよ。
基本的にnewで作ったクラスで必ずdeleteするという規則で
プログラムを組んでいます。
現状これでこと足りるわけですよ。
環境がWindowsなので。
>>961 Windowsでもメモリ管理は重要ですよ。プロセス内部でどうメモリを使うかの問題なので
あまりOSは関係ないと思います。
GCがあるといいなと思うのは
>>959さんの言うように複雑な物(循環参照や解放の責任が点々とするようなもの)を
作らなければならないときですね。
ただGCありの言語だとメモリ以外のリソースへの関心が薄れてしまわないかが心配です。
>>964 だからね。ここでメモリ管理と言っているのは
newの話も含めているの。
あんた、一つレベルがずれてるよ。
そんなに破棄が気になるんなら、
std::auto_ptr<class*> object(new class)
でいいやん。
>>963 こいつはもっとずれてる。まず話に追いついてくれ。
{
std::auto_ptr<class> object(new class)
object->x = pppp ;
}
>>962 何も知らない初心者なんだろ。
メモリ管理ごときに人間様が神経を使う必要はひとかけらも無い。
>>961は早く気付いて周りに迷惑かけないようにしろよ。
971 ：
仕様書無しさん：03/12/07 17:14
＞Windowsのソフトしか組んだこと無いからメモリ管理なんか気にしたことないんだけど。
Windowsだからこそおおいに気にしないとまずいと思う。
>>967 それも一種のGC。GCが不要といっている奴はそれも不要なんだろうね。
ただそれは言語に統合されてないから、不正なメモリアクセスは出来ちゃうし、
それを使うのを忘れれば、やっぱりメモリリークしちゃう。
結局注意しなければいけないわけでプログラマの負担は完全になくならない。
>>957 が作れるような単純なモデルのアプリなら、確かにいらないかも知れない。
だからといって、
「ガベコレ無いと嫌な人って何やってプログラム組んでるの？ 」
と言い張るのは世間知らずといって笑われるだけだ。
たとえば、足し算・引き算しかしないプログラムしか作ったことのない奴が
「動的なメモリ確保ができないと嫌な人って何やってプログラム組んでるの？ 」
って言っていたら、お前どう思う？
じゃ、new と delete のオペレータをオーバーライドして、
allocator<T> もついでに書き換えればいいじゃないか。
new と delete を性的な領域に置き換えればいいじゃないか。
976 ：
仕様書無しさん：03/12/07 17:22
>>965 >あまりOSは関係ないと思います。
でも、私の環境の物理メモリは512MBしかないんですけど、
何故か1250MBまで使えます。
これってやっぱりＯＳがメモリを管理してるってことですよね？
一気に自分で確保してもやっぱりWindowsが管理してる（管理してくれてる）わけですよね？
（まとめてとっているようにみえるが実はＯＳがそのように見せているだけ）
私はWindowsがメモリをどのように管理しているのかそもそも知らないので
この状態で自分でどうこうやるってのはそもそも無駄だと思っています。
し、それを詳しく知っている人にあったことがないのでこういう状態です。
>複雑な物(循環参照や解放の責任が点々とするようなもの)を作らなければならないときですね。
これは当たったことがないので当たってみないとわかりませんね。
>>973 本当に複雑でなければならないプログラムは少ない。
複雑になっているのは設計がクソなだけな場合が多い。
978 ：
仕様書無しさん：03/12/07 17:24
>>976 ＞物理メモリは512MBしかないんですけど、
＞何故か1250MBまで使えます。
仮想記憶って概念を知っているか？
ちょっとイタすぎるぞ
>>976 ＦＭ－ＴＯＷＮＳの時代までタイムマシーンですっ飛んでいけば可能かと。
980 ：
仕様書無しさん：03/12/07 17:26
ＦＭ－ＴＯＷＮＳ は、ＲＡＭ－ＤＩＳＫはあるけど、ＤＩＳＫ－ＲＡＭは
たしかなかったはずだ。
>>976 あまりお話の意図が伝わってこないのですが、
MPUやOSが管理してくれているメモリのレベルと
各プロセスが自分の為に割り当てられたメモリをどう管理するかというのは
基本的に別次元の話ですね。
昨今の環境ならば別プロセスのメモリは保護されているのが普通ですので、なおさらです。
>>978 >仮想記憶
知らないです。
これって掻い摘んでいうとどうなってるわけですか？
知らないのか･･･ 足りないメモリのために、セグメントをディスク上に展開することを言うのだよ。
ちなみに、セグメントを多岐に展開しているＯＳをマルチセグメントモデルという。
32ビットモデルで最大４Tバイトの仮想記憶空間を利用できるのだよ。
>>982 >各プロセスが自分の為に割り当てられたメモリをどう管理するかというのは
>基本的に別次元の話ですね。
>昨今の環境ならば別プロセスのメモリは保護されているのが普通ですので、なおさらです。
各プロセスってなんですか？
割り当てられたメモリっていうことはアプリケーションごと使えるメモリって決まってるってことですか？
>>984 >足りないメモリのために、セグメントをディスク上に展開することを言うのだよ。
そーの辺はなんとなくわかるのですが、問題はその構造です。
足りないメモリのために一度ディスク上におくという動作ってやっぱり
物理メモリとハードディスクにおいてあるメモリといっしょに管理しますよね。
その全権を握っているのがＯＳだと考えてるわけですが違うのでしょうか？
物理メモリ上で連続した領域とアプリケーションから見える連続した領域って
同じものなのでしょうか？
>>987 プロセスはおおまかに言うと一つのアプリケーションみたいなものです。
普通のOSはプロセス単位でメモリを管理します。
ぶつ切りの物理メモリを連続したメモリに見せかけたりしてくれる仕事は
MPUがしてくれます。
申し訳ないのですが、多分ここで逐一説明してもきりがないです。
興味があるのなら本やウェブで調べた方が身になると思います。
物理メモリの効率を良くしたいなら、メモリを大量に積んで、ＯＳの仮想メモリ
を０バイトにすれば、うまく行くんじゃないだろうか？
990 ：
仕様書無しさん：03/12/07 17:49
>>959 GCなかったごときで難しいモデルとは笑い門だな(嘲笑激藁ファック
991 ：
仕様書無しさん：03/12/07 17:50
>>988 大変ためになりました。
ありがとうございました。
個々で知ったキーワードなどを元に自分でも調べてみます>ALL
>>989 それはとんでもなく時間がかかるのでは？
992 ：
仕様書無しさん：03/12/07 17:51
ときどき、GCのおかげでJavaではメモリ開放を手動でできないと
勘違いしている馬鹿がいることにウンザリ
道具は便利になる(=進化する)べきだよな。
GCがあれば解放の心配しなくてすむわけだし。
ただ、GC処理を作る人にとってはメモリ解放のタイミングが難しいだろうけども。
>>990 GCなかったごときで難しいモデルとは笑い門だな(嘲笑激藁ファック
すまん、誰かこれを日本語に翻訳してくれ。
>992
一般プログラマのレベルではSystem.gc や finalize が宛にならないと知っているだけで充分だろう
手動でメモリ管理されたほうが迷惑
996 ：
仕様書無しさん：03/12/07 18:34
>>994 よし！ 俺様は日本語に訳してやるっ！
GCなかったごときで難しいモデルとは笑い者だな(嘲笑激藁ファック
>>993 > 道具は便利になる(=進化する)べきだよな。
>
> GCがあれば解放の心配しなくてすむわけだし。
> ただ、GC処理を作る人にとってはメモリ解放のタイミングが難しいだろうけども。
意味わかっていってんの？
Javaでの手動によるメモリ開放方法は
java.lang.ref.Referenceをつかうんだよ。
ニンテンドーゲームキューブがないごとき難しい型式とは笑い者だな(嘲笑激笑性交
で次スレは？
やったーまんこーひーらいたー！
1001 ：
１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。