やね本発売

**名前は開発中のものです。** · 02/06/01 20:01

LAOX Book館逝ったら、やねうらおの本が売ってました。
という訳で、とりあえず立ててみました。

**名前は開発中のものです。** · 02/06/02 20:52

こういうはなしじゃないの？
↓
------------------
foo1 = new ...
+++++-------------
foo2 = new ...
+++++****---------
foo3 = new ...
+++++****#####----
delete foo2;
+++++----#####----

**名前は開発中のものです。** · 02/06/02 20:53

そんなコードがあるなら最初からmallocなんか存在しねーよ

ﾊｧ?

**名前は開発中のものです。** · 02/06/02 20:54

>>103
そういうときはfoo4をnewするときにfoo2の領域を再利用すれば良いだけ。

**名前は開発中のものです。** · 02/06/02 20:55

>>101
物凄くﾊｽﾞｶﾁｰ発言なんですが、あなた頭大丈夫ですか？

new/deleteをオーバーライドして固定長のバッファを割り当ててやればいいだけ。

89 · 02/06/02 20:55

99は違う人です。

>>100
分断化に（？）つけてる奴に説明できる自信はありません。
とりあえず、Google 検索である程度いけるみたいだからそっちに逝ってくれ。
キーワードはヒープフラグメンテーションだ。
Windows好きなら「喜びと苦悩」とかも読んだらいいかモナぁ。

**名前は開発中のものです。** · 02/06/02 20:55

>>102
ヒープオンリーでメモリ管理できるなんてメモリを最大まで使わない
ギャルゲーぐらいじゃねーの？シーン毎に複雑なテクスチャやモデル
の入れ替えが発生するタイプのゲームではメモリなんてあっというま
にズタズタだよ。

99 · 02/06/02 20:56

>100
すまん、「プログラミング言語Ｃ」を出したのは煽りでは無くてAlloc
の書き方が載ってるんですよ。何ページかは忘れましたが。
もちろん一度newとdeleteしただけでは問題ないですよ。

89 · 02/06/02 20:57

>>106
その「固定長のバッファ」はどこからとってきて、いつ開放されます？
もしかして静的メモリですか？

99 · 02/06/02 20:58

そして「メモリの分断化」って一般的な用語じゃないのね。
混乱させてすまぬ。

**名前は開発中のものです。** · 02/06/02 20:58

>分断化に（？）つけてる奴に説明できる自信はありません。

すまないね。漏れは断片化って言うもんだと思ってたから、
分断化が一般なのか？って意味で（？）をつけた。

**名前は開発中のものです。** · 02/06/02 20:58

はっきりさせておくが、Windowsプログラマが全員、やねさまみたいなプログラマじゃねーぞ。

**名前は開発中のものです。** · 02/06/02 21:00

つーか>>86がヒープ云々を持ち出すから
訳がわからなくなった。

**名前は開発中のものです。** · 02/06/02 21:01

>>114
もちっと、勉強すれ。

**名前は開発中のものです。** · 02/06/02 21:01

>>110
機種依存で良いなら（スタック上など）どのようにでも

**名前は開発中のものです。** · 02/06/02 21:02

>>108
だからさぁ、一つのヒープで全部管理しようというのがそもそも間違いなわけよ。
テクスチャ用ヒープ、モデル用ヒープ、タスク用ヒープ、エフェクト用ヒープ、制御用ヒープ
それぞれ固定長で確保してその中でやりくりするわけ。
またシーンの切り替えなどで定期的にリセットしてやるわけ。
ゲームの進行に関わる重要な部分はスタティックなメモリを使えば良いだけ。

**名前は開発中のものです。** · 02/06/02 21:03

自前メモリマネージャでゲーム中にいつでも断片化状態を見れるようにしてる。
まあタイトな部分はすでメモリプールにしちゃっていたものの、
心配しすぎては損だとの印象を得た。

**名前は開発中のものです。** · 02/06/02 21:04

>116
そういう事ではないよ
君のアロケーターはサイズ指定が出来なくて、必ず同じ大きさの
メモリしか取れんのか？

**名前は開発中のものです。** · 02/06/02 21:04

やね様の本にヒープを前提にすると書いてありましたか？
たとえ書いてあったとしても、それは些細な問題で、
メモリさえ確保できればヒープ上だろうが静的領域だろうが問題じゃありません。
望みのままに逝けます。それを言語の機能やライブラリでサポートした物が
STLのアロケータだったり、newとdeleteのオーバーライドだったりします。

それから、好きな位置に確保できる配置newという構文も用意されてます。

89 · 02/06/02 21:05

>>112
あー、そういうことでしたか。
まぁ簡単な例だと、 >>102 あたりだとおもいます。
>>116
粘着ですんませんが、
どのように取ってきたメモリでも、固定長バッファとして割り当てられるような
new/deleteのオーバーロードの仕方を教えてください。

**名前は開発中のものです。** · 02/06/02 21:05

メモリ、メモリ、ってうるせーなー

メモリリークしたくらいで、プログラムが止まるわけねーだろ。

86 · 02/06/02 21:05

>>114
申し訳ないです。ここまでの流れを見てもらえば解るようにコンスマ
とウインにはメモリ管理に大きな壁があるのですよ。それはもう実績
から来る理論なのでここであーだこーだゆーても決着はつかんですね。

で、自分の目から見てコードサイズが膨れ上がるstlをベースにライブ
ラリ設計していたりとか、メモリへの危機感が少ないなーと。ただそ
れだけの感想です。

もちろん一般的なWinプログラマはちゃんと諸々の問題に真剣に取り組
んでいる事ぐらいは知っていますよ。（エログラマは怪しいが）

**名前は開発中のものです。** · 02/06/02 21:06

>117
やね本には、そんな高度な事は書いてないに違いない。

**名前は開発中のものです。** · 02/06/02 21:07

>>115
？
>>79はWinプログラマはメモリ管理が杜撰だと言ってるのに対して
>>86がヒープ使ってるから駄目だと言い出したのが原因じゃん。
メモリ管理と銘打つ以上スタックだろうがヒープだろうが
リークは起こるんだよ。
プログラム側で、スタックの上のあるメモリ領域が使用中だと判断すれば
他の目的には使えないことには変わりないんだから。

**名前は開発中のものです。** · 02/06/02 21:08

>>110
静的メモリでも、動的メモリでもお好きなように。
4byte要求されても、224byte要求されても256byteずつ割り当ていれば断片化は起こらんでしょ。
256byte以上要求されたら、NULLを返す。

当たり前だけど、汎用には使えないから対象となるクラスのnew/deleteだけをオーバーライドするんだけどね。

**名前は開発中のものです。** · 02/06/02 21:11

＞１２２
＞メモリリークしたくらいで、プログラムが止まるわけねーだろ。

メモリリークは >79 が、
>エロゲーでメモリーリーク起こして止まる奴とかが多い理由がよーく解ったよ。
と知ったかぶりしてるだけなので、無視しときましょ。

**名前は開発中のものです。** · 02/06/02 21:12

>>123
今後は特殊な例を出してそれを一般化するのはﾔﾒﾚ

**名前は開発中のものです。** · 02/06/02 21:13

>126も十分特殊だと思うが。

**名前は開発中のものです。** · 02/06/02 21:13

ゲ製板にmalloc論争スレがないのが前から気になってたんだよな

**名前は開発中のものです。** · 02/06/02 21:14

>>127
　いや、いろんなものの開放し忘れで止まるエロゲー多いよ。
大体は発売後のパッチで直るけどね。79は単純にそういう危機感の
無さを指摘してるだけだとおもうよ。ねぇ、やねうらおさん？

**名前は開発中のものです。** · 02/06/02 21:15

そりゃコンシューマとWinではメモリの使い方に対して方針が違ってきて当たり前でしょう

**名前は開発中のものです。** · 02/06/02 21:15

>>121
class Texture
{
　static void* heap;
　size_t index;
public:
　inline operator new(size_t size)
　{ return static_cast<char*>(heap) + index; }
　operator delete();
};
void* Texture::heap = （望みのままに）;
こんな感じでテクスチャごとだったり、モデルごとにヒープを確保できて、
勿論operator newの中身は書く。

void* global_heap = （利用可能なメモリすべて）;
として、グローバルなoperator newを定義すればすべての管理を掌握出来、

char buf[0x1000];
new(buf) Object;
これでbuf上にオブジェクトを作成できる。

C++の基礎中の基礎

**名前は開発中のものです。** · 02/06/02 21:16

つーかコンピューターの進化って
大局的には、STLとかそういう便利な機能を
使えるようにする為にあると思うんだよなぁ。
文句を言うべきなのは、クラシックな方法を強いる
環境の方だよ。

**名前は開発中のものです。** · 02/06/02 21:17

smart_ptr等にはつかっちゃいけない場面があって、
それを知らないとハマるかもしれないことは分かります。
で、real smart pointerはそのへんの心配はないのでしょうか？

**名前は開発中のものです。** · 02/06/02 21:18

>>131
頼むから名前を挙げてくれ。
解放し忘れただけで止まるプログラムなんか知らない。
メモリを食いつぶすだけだろ。
（Winにおいて）リソースリークは深刻だが。

**名前は開発中のものです。** · 02/06/02 21:18

そもそもこの言い争いは、「ＧＴＬは日本最強」とか言い出した人がいたから
発生した気がする。
ライブラリスレも同じように荒れた記憶があるのだが。

**名前は開発中のものです。** · 02/06/02 21:18

Windowsプログラムはメモリーが無限大であることが前提
足りなければ増設してください、貧乏人

**名前は開発中のものです。** · 02/06/02 21:19

>>134
そうゆう方向に進化した唯一のハードであるXBOX様がいま命の灯火を消そ
うとしているところなのでヒープとの果てしない争いは終わる事が無いと
思われ。

**名前は開発中のものです。** · 02/06/02 21:19

boost::shared_ptr等に代表される参照カウント式のスマートポインタは、
巡回参照にさえ気をつけていれば問題ない（リークは起きない）。
real smart pointerって何か知らないんだけど、GCのサブセットか何か？

**名前は開発中のものです。** · 02/06/02 21:19

富豪的プログラミングはゲームにおいてはやはりまだ厳しいのか

**名前は開発中のものです。** · 02/06/02 21:20

>136
だから、知ったか厨は無視しましょ。

**名前は開発中のものです。** · 02/06/02 21:21

つーか俺はスマートポインタなんぞ使いたいと思ったことがないなぁ。
確保したら開放する、これの方がすっきりして気持ちイイじゃん。
皆さんはどう？

**名前は開発中のものです。** · 02/06/02 21:22

>>129
オヤジが良く使う、固定長バッファのタスクシステムと何が違うのかと小一時間・・・。

**名前は開発中のものです。** · 02/06/02 21:22

>>137
それって78の記事？
直接この流れには関係ないと思うが。
事実、裏男のライブラリよりもNxDrawよりもVafxImg（だっけ？）よりも
素晴らしいテンプレートの使い方をしていると思うよ、GTLは。

**名前は開発中のものです。** · 02/06/02 21:22

>>142
イタタ…。

**名前は開発中のものです。** · 02/06/02 21:22

STLってデバッカで追う時めんどくさくない？
漏れはそれだけの理由で避けてます（笑。

毎回似たようなクラス（双方向リストとか）書くのは
確かに効率悪いけど、自分の勉強の為には結構
役立ったと思うのだが。

**名前は開発中のものです。** · 02/06/02 21:24

>>140
0xffffffff回以上の参照が起こった場合は大丈夫なの？
あと、循環参照ってどこで発生するかわからないから怖いね。
相互参照ぐらいなら把握可能なのだが。

**143** · 02/06/02 21:24

ああでもSTLは使ってるなあ。
あれもスマートポインタみたいなもんだなあ。
>>143は撤回しまぷ。

**名前は開発中のものです。** · 02/06/02 21:24

>>147
勉強にはなるだろうけど、実際に使うときは広く使われているものの方が
問題があるのかどうかが分かってていいでしょ（いろんな人の目に触れてるわけだから）

**名前は開発中のものです。** · 02/06/02 21:24

>>147
漏れの場合、はじめはSTLは無条件に正しいと信じてStepOverしてます。
で、どうしても解決しないときのみSTLの内部にStepInします。

>>146
142が痛いなら、メモリの解放し忘れで落ちるプログラムを上げてください。
別に市販のエロゲでも人命に関わるシステムでもかまいません。

**おらうねや** · 02/06/02 21:25

おまえら本買ってね、よろしこ！

**名前は開発中のものです。** · 02/06/02 21:25

アクセスバイオレーションはメモリリークに入る？

**名前は開発中のものです。** · 02/06/02 21:26

本の内容以上に高度なスレになっている

**名前は開発中のものです。** · 02/06/02 21:26

>>147
俺の場合逆。
STL自体にはバグがないことが保障されているから、安心して使える。
毎回似たようなクラスを書いていると、そこにいつバグが入るかわからないから不安。

**名前は開発中のものです。** · 02/06/02 21:26

結構スレが伸びたが、どれくらい売上に貢献するのだろう・・・

**名前は開発中のものです。** · 02/06/02 21:29

>>151
　何をムキになってんだか。

>>解放し忘れただけで止まるプログラムなんか知らない。

　これがイタイってだけですが？

**名前は開発中のものです。** · 02/06/02 21:29

>>153
入りません。ってか、ネタ？

**名前は開発中のものです。** · 02/06/02 21:31

アクセスバイブレーションで彼女に参照すると、液体がリークします
が、何か？

**名前は開発中のものです。** · 02/06/02 21:37

>これがイタイってだけですが？

解放忘れだけで止まるプログラムあるんですか？
マジでわからん。

**名前は開発中のものです。** · 02/06/02 21:40

>>160
１、スワップ大量に発生して、止まったように見える
２、newしたところ、NULLが返ってきて、NULL参照で落ちる。
のどっちかかと。

**名前は開発中のものです。** · 02/06/02 21:40

>>157
ま、そうムキにならずに。

エロゲなんで、プラットフォームはWinを前提に話すけど、
深刻なリソースリークを除いて、メモリリーク程度で止まるようなことはまずないよ。

強制終了するのは、ほとんどアクセス違反じゃねーの？
固まるってのは、ループの終了条件ミスってるとか。
マルチスレッドのゲームも珍しくないけど、デッドロックしてるのもあったし。

**名前は開発中のものです。** · 02/06/02 21:45

っていうか、なんで「メモリリーク」ごときでこんなに盛り上がれるのか、理由を言ってみろ。

**名前は開発中のものです。** · 02/06/02 21:45

>>161
1 普通はDMA転送になるから、スワップアウト程度でアプリが固まることはまず無い（9xは知らん）
2 それはリークではなくて、エラーリカバリが甘いだけ。

**名前は開発中のものです。** · 02/06/02 21:47

>>163
断片化の話題が終了したから（内心は79が謝らないから藁）

**おらうねや** · 02/06/02 21:47

>>163
房やだからさ

**157** · 02/06/02 21:48

>>162
　んにゃ、なんかスレの流れ上メモリリークの件が何故か漏れに
押し付けられてるんだけど、別にエロゲ云々言い出したのは別の
人なんだよね。

　まぁそれはともかく、止まる止まらないはともかく、メモリリーク
なんて恥ずかしい物を止まらないからOKってのがイタイなと思っただけ。

**名前は開発中のものです。** · 02/06/02 21:50

>>164
ハードディスクのスワップ領域を全部食い尽くしたら止まりそうな気が・・・。

**名前は開発中のものです。** · 02/06/02 21:50

>止まらないからOKってのがイタイなと思っただけ
だれもこんな事言ってないって。
79の記事から読めば分かるだろう

**162** · 02/06/02 21:52

>>167
>メモリリークなんて恥ずかしい物を止まらないからOKってのがイタイなと思っただけ。
誰もそんなこと言ってませんがな（ｗ

「メモリリークで止まるエロゲが多い」って言葉に、つっこんでるだけだと思ってたけど。

**名前は開発中のものです。** · 02/06/02 21:53

>>168
その時はネット空間にでもスワップさせますから
大丈V！！

**名前は開発中のものです。** · 02/06/02 21:53

>>169
ハードディスクのスワップ領域を食いつぶさなくても
ユーザーアドレスの空間をすべて（2Gだっけ？）食いつぶせば、
それ以上スワップは増えずにメモリは確保できなくなる。
確保できなくなるから、NULLが返ったり例外が発生したりする。
それを適切に処理出来ないから固まる。
適切に処理できているなら、いきなり固まらずに何かしらアクションを起こしてくるはず。

**名前は開発中のものです。** · 02/06/02 21:55

>172
まぁ、そこまで大量にメモリリークするゲームってのは滅多に無いけどね

**名前は開発中のものです。** · 02/06/02 21:56

>>172
メモリ確保するたびにNULLチェックをするような神経質な奴が、
そんな深刻なメモリリークを起こすとは思えない。

**名前は開発中のものです。** · 02/06/02 21:56

>>172
2G食いつぶすほどのメモリリークて・・。
メモリリークっていうよりメモリ堤防大決壊って感じ。

**157** · 02/06/02 21:56

>>170
んじゃ根本的に論点がずれてるね。すまんそ。

ちなみにあたいは数キロの開放し忘れでメモリが確保できなくなる
環境でお仕事していますものでその辺シビアなのですよ。実はちょっ
と羨ましかったり。

**名前は開発中のものです。** · 02/06/02 21:57

>>176
そんなシビアな環境でヒープなんて使うなよという気がする。

**名前は開発中のものです。** · 02/06/02 21:58

>>176
ぴゅー太ですか？(ﾜﾗ

**名前は開発中のものです。** · 02/06/02 21:59

>>173-175
その通りだけど、メモリリークが原因で落ちると言うことの反論として（藁
実際に、そこまで激しくリークしてもリークが原因で死ぬことはないと。

**名前は開発中のものです。** · 02/06/02 22:04

スレと関係なくて申し訳ないのですが、助けてください。
VC++6.0でSTLを使おうと思ったのですが、サンプルに書いてある
通り
vector<int> test;
test.push_back( 42 );
と書いたらNULLでFreeして落ちるのですが。
どうも
_Firstも_Lastも_EndもNULLみたいなんですが。

**名前は開発中のものです。** · 02/06/02 22:06

>>180
F r e e す　ん　な　タ　コ

　　　　　　　　　　　　解決

**180** · 02/06/02 22:07

いえ、STL内部でFreeしてるので、もうにもこうにも。

**名前は開発中のものです。** · 02/06/02 22:09

NULLでFreeするってなんだ？

**名前は開発中のものです。** · 02/06/02 22:10

殺伐としたスレの流れを癒してくれた180に感謝。
それにしてもヒープ談義はプログラム板でも毎回盛り上がるねぇ。

**名前は開発中のものです。** · 02/06/02 22:11

>>180
君、事実を述べてないんじゃないの？
本当にint？
ポインタだったりするんじゃないの？

**180** · 02/06/02 22:15

>185
いや、本当にこれしか書いてません。
どうも
vector<int> test;
と書いた時点で入れるデータ用にメモリを確保してないらしく、
test.push_back(42)
の中で末端を見てるのですが、末端は0x00000の割に何もチェック
をしてないみたいです。

**名前は開発中のものです。** · 02/06/02 22:16

SP当ててる？

**180** · 02/06/02 22:17

>187
SP4を当ててます。

89 · 02/06/02 22:19

>>133
わざわざ、ありがとう。
派生、配列確保などを禁止してよい場合なら、そんな感じでいけます。
負け惜しみっぽい突っ込みでごめんよ。
もうこのスレではこの手の話はしないよ。

**名前は開発中のものです。** · 02/06/02 22:20

つーかさ、勝手に内部の_Firstとかをみてるわけ？
一度 test.begin() とかやってイテレータを生成してみたら？

! · 02/06/02 22:22

http://www.twin.ne.jp/~ackey/

**名前は開発中のものです。** · 02/06/02 22:24

>派生、配列確保などを禁止してよい場合なら
頭、固いね。

**名前は開発中のものです。** · 02/06/02 22:25

include から、main からすべてのソースを書け。
そこ以外に原因があるとしか思えん

**180** · 02/06/02 22:28

すいません、原因がわかりました。
STL以外にもライブラリを使ってるのですが、それがdeleteを
オーバーライドしてまして、それが悪さをしてたみたいです。
でも、FreeにNULLが渡る事は変らないです。
そういう仕様みたいですね。

大変お騒がせしました。
もう帰って寝ます。

**名前は開発中のものです。** · 02/06/02 22:29

>>130
そーなのか
この板あまり見ないけど、他板と同様に思い出したように
これと同じ話題・同じ展開を月１くらいでやってそうなイメージがある

**名前は開発中のものです。** · 02/06/02 22:30

>>194
そんなのやる前から予想できることじゃんか（藁

**名前は開発中のものです。** · 02/06/02 22:31

メモリリークより、ファイルをオープンしっぱなしのほうが深刻だと思うぞ。

（って、もう鎮火しちゃったのね…残念

**名前は開発中のものです。** · 02/06/02 22:32

>>195
たててみようか。Win対コンシューマの暑い論争キボン

**おらうねや** · 02/06/02 22:33

>>198
そゆことするから厨房ってゆうんよ

**名前は開発中のものです。** · 02/06/02 22:35

>>198
いや、辞めようよ。プラットフォームが違うんだから問題点も違う
のは当たり前で
「メモリリークぐらいじゃ止まらんわボケ」
「メモリ断片化の恐怖を知らんのかボケ」
の両意見が相容れる事なんてありえない。

**名前は開発中のものです。** · 02/06/02 22:37

>>198
中途半端な知識を用いた香ばしい戦いの予感

　　糞　ス　レ　立　て　る　な

**198** · 02/06/02 22:42

http://game.2ch.net/test/read.cgi/gamedev/1013512099/l50
ｳﾌﾌﾌ