OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

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

>>777
　ああ、タスク毎の処理は１種類で、当たり判定の処理（タスク実行順に
依存したくない処理）はタスクマネージャーがグローバルに行う、ってわ
けですね。
（´ー｀）。oO（本当、人それぞれだなぁ）　

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

このスレの最初のほうにCとC++ではCの方がC++で作ったときよりも
実行速度が速い、もしくは同等と書かれていたんだけど、
ヘボプログラマはCで作っておいたほうが無難ということなの？
そこで言われているCとC++との違いはクラスの使用から来るもの？

**名前は開発中のものです。** · 02/03/20 07:15

>>780
実際にわずかなオーバーヘッドがあるし、まずい設計では
暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
C++についてよく理解してないと、ただ遅いだけの道具になるよ。

**781** · 02/03/20 07:18

C と C++ の違いは主にクラスによる。
同一な C プログラムなら C++ でコンパイルしても
速度はほぼ同一なはず。ライブラリとか最適化の具合にももちろんよるけど。

**名前は開発中のものです。** · 02/03/20 11:13

>>780
書籍「Inside the C++ Object Model」で詳細に解析してるから、それを
読むのがいいと思うが。

メンバ関数（メソッド）を呼び出す場合に this が暗黙のうちに渡されたり、
仮想関数を呼び出すと間接参照が何度か（一般には 2 回）入ったりす
る。ただ、このあたりのことは C でも同じ処理をやろうと思ったら、

　関数の引数として、構造体へのポインタを渡す
　関数ポインタを使う

必要があるから、ホントは変わらないんだけど。

> 暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
synthesize constructor / destructor のことを言ってるんだと思うが、
それなら C だって「初期化処理を入れたら遅くなる」というのと同じ。
trivial constructor / destructor で済むクラスなら、初期化・終了処
理を省くことも出来るし。

C でも C++ でも「同じ処理をさせよう」と思うと、実際には「同じだけの
コストがかかる」ことになる。ただ C++ では、synthesize constructor/
destrurctor や temporary object のように

　コンパイラが、見えないところでコードを付け加える

ことがあるから、そこを意識していないと、たった数行のコードなのに
コンパイルすると数千命令に展開されていた、ということが有りうるの
で注意が必要。

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

>>778
　フォトショップのレイヤーを思い浮かべると良いと思われ。
　当たり判定を取る当たり同士をグループ化して、グループに番号を付けておく。

　進入禁止系のあたりをレイヤー０番に置くとして、壁、NPC、敵キャラのあたりは
HitMe( ???, 0)と呼び出してやる。プレイヤーオブジェクトはそれが壁なのかNPCな
のか区別せずにすむ。
　で、レイヤー１番はアイテム系の判定として、アイテムオブジェクトとプレイヤー
オブジェクトだけが所属する。そうすればNPCオブジェクトの方で接触のあった
オブジェクトがアイテムだったら何もしない、なんてコードを書かなくて済む、と。

　こんな感じ？

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

すげぇ、この板に役に立つスレがあったのか。

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

>>784
なるほど。参考になったよ。

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

レイヤー化って、OS－ミドルウェア－アプリケーションみたいなプログラムの階層化と思ってたけど、違ったのね

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

>>784
　すまそん。マスター入れてやっと家に帰って来れました。

　レイヤー化のメリットはまさに784さんの言うとおり。汎用的な当たり判定管理クラスを
１つ作ってあとはゲームデザイン次第でプログラマが自由にレイヤーを利用みたいな感じね。

　更なるメリットとしてヒットアルゴリズムの分離ってのもありまして。
「矩形の重なりによるヒット判定」
「球形や線分との距離による判定」
「背景物のようなｎ次元マップデータとの判定」
「ランドスケープやポリゴン等のベクトルデータとの判定」
など、これまたゲームデザインの要求に応じて利用/拡張すればいいと。
はっきりいってこの機構自体は１個作っちゃえば３Dゲームにもバリバリ
に応用できるし、斑鳩みたいな２Dの３Dの混在なんかも結構簡単に出来
るよね？

　ただまぁ、C++としての実装は自分はヘタッピなのでだれか上手い実装例
をみせてくれないかなーと。テヘッ。

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

コールバック関数による当たり判定って

全キャラクタのタスク更新
↓
判定管理クラスの関数を呼び出し→各キャラクタのタスクのコールバック関数呼び出し
↓
描画

みたいな流れかと思ったんですが、
コールバック関数内でタスクの状態（位置など）を変化させられないと、
キャラクタ同士めり込んだ状態とかで描画されてしまいますよね？
その辺はどう処理されてるのでしょうか？

**名前は開発中のものです。** · 02/03/24 05:59

良スレなのでage

02/03/24 09:15

C++なんぞOOPLではないのでsage

**名前は開発中のものです。** · 02/03/24 11:04

>>788
なるほど、それは便利だ。
ちゅうか今、当たり判定で困ってるところなんだわ。

>>791
すでにそんなことはどうでもいい

**名前は開発中のものです。** · 02/03/24 11:12

>791
マ板で語り尽くされた事を隔離板で吠えられてもﾅｧ...
つーか、sagaってねぇし（藁

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

>>789
俺の場合、基本的にあたり判定の中では当たったかどうかの判定だけで
めり込んでも無視です。
当たり中に状態変化(移動、フラグ立てなど)を行うと実効順によってそれ
以降の判定が異なってしまうからです。
どうしてもやりたい場合、完全な例外処理ですね。
こいつはこういう処理だから気をつけるとかコメント書いてます。
つーか、うまい処理が思いつかん。

**名前は開発中のものです。** · 02/03/31 00:07

このスレに影響されて、当たり判定管理クラスを構築中age

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

頑張れー＆公開キボン。

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

当たり判定はその処理のタイミングも必要なので、
それ単体をクラスで定義しただけでは難しいと思うのだが
何かいい解決手段あったらよろしく

**名前は開発中のものです。** · 02/03/31 09:34

>>764
それだと、当たり判定の種類毎にレイヤー用意しなきゃいけなくなって面倒じゃない？

**798** · 02/03/31 09:40

>>764
じゃなくて
>>784
でした。

**名前は開発中のものです。** · 02/03/31 11:32

800get

**関係ないが** · 02/04/01 00:49

最近C++でゲーム開発しているんだが、ヘッダーファイルをincludeするだけで
最終コードのサイズが増えるという現象に遭遇して思いっきり萎え。
コンパイラのバグだがあまりにもひどいっす。
Cならこんなことはならないよなぁ・・

**名前は開発中のものです。** · 02/04/01 00:56

どのコンパイラ？

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

CWだな…。オレも経験済み。

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

参照してないシンボルもリンクしちゃうってこと？ >>801

**801** · 02/04/01 02:25

g++なんだがCWでもあるんか・・。
classの中のstaticなinline関数が関数ローカルのstatic変数を持つコードが
あると、その関数を一度も使わなくともコード、データ領域ともその翻訳処理
単位で展開されてしまうんだよ。いわゆるシングルトンパターンの構造をもつ
ヘッダファイルをインクルードするだけで飛躍的にコード、データサイズが増加する
罠。
やっぱC++は組み込みには向いてないよな・・・。

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

組み込みだからって、そんな関数なんでinlineにすんだよ？>>801

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

>>805
ちなみに gcc のバージョンいくつ？

**801** · 02/04/01 02:34

class foo {
static foo& Instance() {
static foo bar;
reurn bar;
}
}

これだけですが何か？

**801** · 02/04/01 02:36

>>807
2.9-9911、2.96-1003、2.96-1003-1で確認したよ。

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

>>808
parse error だぞ（ｗ　まぁ、言いたい事は分かるから問題ないけど。

今、手元の gcc 2.95.3 (cygwin-special) で

class foo
{
public:
　　static foo& Instance()
　　{
　　　　static foo bar;
　　　　return bar;
　　}
};

void func() { foo s; }

だけのコードを g++ -S でコンパイルしてみたが、確かに .lcomm セクションに
変数 bar が確保されちゃうね。Borland C++ Compiler 5.5.1 や Visual C++
6.0 だと

警告 W8027 singleton.cpp 6: <静的変数>を含む関数はインライン展開できない(関数 fo
o::Instance() )
singleton.cpp(15) : warning C4514: 'Instance' : 参照されていないｲﾝﾗｲﾝ関数は削除
されました。

となって、いずれのケースでも出力されたアセンブリコードに bar は存在しない。

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

>>801
inlineにしなくてもまともな実現方法がいくらでもあるんだから、
> C++は組み込みには向いてない
なんてことにはならんだろ。

**名前は開発中のものです。** · 02/05/16 11:00

保守ageついでに。上っ面撫でてるだけの記事だけど。

GameDev.net - Object-Oriented Scene Management
http://www.gamedev.net/reference/articles/article1812.asp

**名前は開発中のものです。** · 02/08/15 13:27

保守age

OOのゲームプログラミングへの応用ということで、シリアライズの話を。
いつでもどこでもセーブできて、その場の状況を完全再現するには
シリアライズしかないと思うが、やったこと無いので良くわからず。

MFCなんかでやれるオブジェクトの動的生成って全部自前で実装する場合
どうやったら良いんだ？

**名前は開発中のものです。** · 02/08/15 14:23

クラスファクトリを作って、
IDとクラスを1:1でマッピング。
読み込み時にIDによって生成するクラスを決める。

**名前は開発中のものです。** · 02/08/15 14:47

>>813
> MFCなんかでやれるオブジェクトの動的生成って全部自前で実装する場合
> どうやったら良いんだ？
エピステーメーの「オブジェクト指向的日常」って本で、簡単な解説と実装例を
紹介をしてた。（初版ではコードに致命的なミスがあったりしたが……）

**名前は開発中のものです。** · 02/08/15 14:57

生成プログラムをスマートに抽象化するとしたら？

**名前は開発中のものです。** · 02/08/15 17:33

>>816
クラスファクトリを static オブジェクト化して、別の static オブジェクトに登録。
main が走り始めた段階で準備完了、としておく。

**名前は開発中のものです。** · 02/08/15 17:58

簡単な実装例キボン

**名前は開発中のものです。** · 02/08/15 19:30

>>818
マジメに書くと長くなるんだが…。昔のコードから抜粋すると、こんな感じ。

// 永続オブジェクト基底クラス
class CPObject {
private:
　　static const BYTE bytMagic[3];
　　static const UINT MAGICLEN;

public:
　　virtual ~CPObject() {}
　　virtual BOOL equalsTo(const CPObject* obj) const {
　　　　return this == obj;
　　}
　　virtual BOOL saveIt (FILE*) const = 0;
　　virtual BOOL restoreIt(FILE*) = 0;
　　void save(FILE*) const;
　　static CPObject* restore(FILE*);

　　virtual UINT isA() const = 0;
};

**名前は開発中のものです。** · 02/08/15 19:31

// 永続オブジェクト ID 辞書クラス
class CPIDDict {
private:
　　struct CPIDRec {
　　　　UINT id;
　　　　CPObject* (*func)();
　　};
　　CPIDRec* array;
　　UINT size;
　　UINT cap;
　　CPIDDict(const CPIDDict&);
　　CPIDDict& operator=(const CPIDDict&);

public:
　　CPIDDict();
　　~CPIDDict();
　　static CPIDDict* theCreator();
　　void regist(UINT, CPObject* (*)());
　　CPObject* create(UINT) const;
};

**名前は開発中のものです。** · 02/08/15 19:32

// ファクトリを ID 辞書に登録する
// クラス実装ファイル (*.cpp) の先頭に記述
#define REGISTER_CPOBJECT(X, ID) \
static CPObject* X ## creator() { return new X; } \
class X ## Creator { public: X ## Creator(); }; \
X ## Creator::X ## Creator() {\
　　　　CPIDDict::theCreator()->regist(ID, X ## creator);\
};\
static X ## Creator X ## dummy __UNUSED__;

// 永続オブジェクト関連メソッドの宣言
// クラスへッダファイル (*.h) の public セクションに記述
#define DECLARE_CPOBJECT(ID) \
virtual BOOL saveIt(FILE*) const;\
virtual BOOL restoreIt(FILE*);\
virtual UINT isA() const {\
　　　　return ID;\
}

#define RESTORE_CPOBJECT(TYPE, FP) \
　　　　(dynamic_cast<TYPE>(CPObject::restore(FP)))

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

class Class { public: virtual ~Class(){} };
typedef int ID;
class IGenerator;
class ClassFactory : private map<ID,IGenerator*>
{
typedef map<ID,IGenerator*> Base;
public:
bool can_create( const ID& id ) const { return ( Base::find( id ) != Base::end() ); }
void insert( const ID& id , IGenerator* const p ) { Base::insert( make_pair( id , p ) ); }

template<class CLASS>
auto_ptr<CLASS> create( const ID& id ) const
{
Base::const_iterator const found = Base::find( id );
return auto_ptr<CLASS>( ( found != Base::end() && found->second )
? dynamic_cast<CLASS*>( found->second->Generate().release() )
: 0 );
}
};
ClassFactory& getClassFactory() { static ClassFactory instance; return instance; }
struct IGenerator
{
IGenerator( ID id ) { getClassFactory().insert( id , this ); }
virtual ~IGenerator(){}
virtual auto_ptr<Class> Generate() = 0;
};

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

class MyClass : public Class
{
public:
static const ID key;
MyClass(){}
private:
struct Generator : IGenerator
{
Generator() : IGenerator( MyClass::key ) {}
auto_ptr<Class> Generate() { return auto_ptr<Class>( new MyClass ); }
};
static Generator generator;
};
const ID MyClass::key = 12345;
MyClass::Generator MyClass::generator;

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

int main()
{
cout << "create MyClass by correct key... ";
auto_ptr<MyClass> p1 = getClassFactory().create<MyClass>( MyClass::key );
cout << ( p1.get() ? "ok" : "ng" ) << endl;

cout << "create MyClass by wrong key... ";
auto_ptr<MyClass> p2 = getClassFactory().create<MyClass>( 100 );
cout << ( p2.get() ? "ok" : "ng" ) << endl;

return 0;
}

修正 · 02/08/15 23:05

template<class CLASS>
auto_ptr<CLASS> ClassFactory::create( const ID& id ) const
{
Base::const_iterator const found = Base::find( id );
if( found != Base::end() )
{
IGenerator* const p = found->second;
if( p )
{
auto_ptr<Class> pbase = p->Generate();
CLASS* const ptest = dynamic_cast<CLASS*>( pbase.get() );
if( ptest )
{
pbase.release();
return auto_ptr<CLASS>( ptest );
}
}
}
return auto_ptr<CLASS>();
}

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/08/16 00:57

シリアライズ＝排他処理

**名前は開発中のものです。** · 02/08/17 20:32

尻穴is=排泄処理

**813** · 02/08/18 17:49

おお、解説＆ソースうｐありがとうございます。
（って、まだ全部ちゃんと読んでないですが）

ちょっくらやってみるか。ってシリアライズなしでやってたものに
シリアライズつけるの厳しそうだな……（いちおうスーパークラスはあるんだけど）

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

>>828

ﾜﾗﾀ

**名無しさん** · 02/10/06 17:40

あ３ｗ４５えｒｇｔｙくぉえぴＶん：http://genie.gaiax.com/home/nakatai
ＨＧＢＴＲ４ＭＨＧＢＰ０Ｔ５え＠ご９ＪＲ４ＱＰＶ「Ｊる５ＶＧ
ＤＢ５ＶＨＧ４ヴぇＲ４ＴＰヴぇＲ５ＭＨＧＢＴじhttp://genie.gaiax.com/home/nakatai
http://genie.gaiax.com/home/nakatai
さＤＲＧヴぁでＲＧＢはえ；んごいえろげいＲ
あえＲＳＨＧべＳＤＲＨＤＳＶＧＤＲＦせＶＤＲＦせＶせＤＦＧＶＲＦせＤヴぇＤＲＦＳげＤＦＳ
http://genie.gaiax.com/home/nakatai

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/10/28 04:08

ほしゅ

**名前は開発中のものです。** · 02/11/03 01:14

OOってそれぞれの人で考えてる程度が違うから、
チーム開発に適用するのは難しいよね。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 02/11/03 01:35

>>834
＞ OOってそれぞれの人で考えてる程度が違うから、
プログラミング自体それぞれの人で考えてる程度が違う

**名前は開発中のものです。** · 02/11/03 10:51

なんつーか、あれだよ。
まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
いうことを同僚にたたき込む方法を教えてくれ。

**名前は開発中のものです。** · 02/11/03 10:59

>>837
どいうレバルで？VCとかだとコンパイル時間早くするためにやったりするし。
ライブラリレイヤーなんか#include "KaisyaLib.h"で済ませちゃうのが普通じゃない？

アプリケーションレイヤーでそれやられると結構泣けるな。

**あぼーん** · NG

あぼーん

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

てことはstdafx.hもアウトか？

**名前は開発中のものです。** · 02/11/03 16:12

>>837
そいつは、ずっと一人（多くてせいぜい2人）で開発をしてきたか
もしくはソースコードの管理はその一人で（しかも人力で）やってきたか
多人数で効率よく開発する仕組みを全く知らなくても良い立場なんだろ。
　
　
他のモジュールとの依存関係を把握してない。orしたくない。orする必要ない。
　　↓
とりあえず全部インクルードしちゃえ。単体テスト不能？知るかボケ。
　　↓
いきなり結合テスト。make時にリンクされるモジュールが具体的に
どれなのか勿論分かってない。まぁ他のモジュールは全て安定版と
確信してるから何も問題ないね。根拠？知るかボケ。
　　↓
不具合を確認。デバッグ作業開始。3日経過。あ、ボスが来た。
「ボス：どうかね、進捗のほうは」「漏れ：はい順調です（苦笑）」

**841** · 02/11/03 16:20

複数メンバーとの並行作業が事実上不可能。
　
実際にやったら
あちこちに（作業上の）クリティカルセクションがありそうだ。
ある一人のデバッグ作業が終了するまで他の全ての人間の作業が
停止することが日常茶飯事みたいな。
　
的外れだったらｽﾏﾝ。

**名前は開発中のものです。** · 02/11/03 16:30

>まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
これがよくわからんが、プロジェクト中の自分が使わないヘッダファイルまでインクルードするってことか？

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

開発当初から最後まで一貫して手を入れずに使い続けるようなものは
ある程度の単位にパッケージ化して（安定した）基本セットとして渡す
ことはよくあるな。
　
もっともそれは#include <xxxx.h>がずらーりと並ぶようなヘッダファイルを
用意するということではなく、リリース用の.oファイルと.hファイルのセットを
用意（というか自動生成）するという意味だが。

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

VCなら.libと.hか。

**名前は開発中のものです。** · 02/11/03 18:46

>>843
それやられると、一つのヘッダを書き換えただけで常にフルビルド状態に
なっちゃうんだよね。特に、前方宣言ですむところを #include するのは
犯罪だ。

**名前は開発中のものです。** · 02/11/03 19:14

VC++ならプリコンパイル済みヘッダがあるので
コンパイル時間については心配いらないんだけどね。

ヘボいコンパイラしかない環境って悲惨だね。

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

837ですけど。
841さんと842さんのいう状況そのまんまで爆笑しました。
なんつーか説得は不可能ですよね。
なにいっているかわからない人はわからなくていいです。
そのほうが幸せだと思います。

**名前は開発中のものです。** · 02/11/03 20:56

>>847
意地の悪い質問で恐縮だが、ぜひ質問させてくれ。
　
00.cpp
01.cpp
02.cpp
03.cpp
(中略)
fe.cpp
ff.cpp
の先頭部分でそれぞれ
#include "00.hpp"
#include "01.hpp"
#include "02.hpp"
#include "03.hpp"
(中略)
#include "fe.hpp"
#include "ff.hpp"
という具合にインクルードしてたとして
00.hppを書き換えてmakeしても時間を気にする必要がないのか。
　
本当か？

**849** · 02/11/03 21:08

いや、ゴメン。訂正。
　
#include "00.hpp"
#include "01.hpp"
#include "02.hpp"
#include "03.hpp"
(中略)
#include "fe.hpp"
#include "ff.hpp"
　
という内容のmarugoto.hppなるヘッダファイルを用意。
で、全ての.cppファイルの先頭で

#include "marugoto.hpp"

みたいな感じかな。スレの流れ的にいうと。

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

>>849-850
そのケースだと、最初の.cppをコンパイルするときに
プリコンパイル済みヘッダーが作られて(marugoto.hppを指定する)、
それ以降はそのヘッダを使いまわすことになります。
つまりmarugoto.hppとそのファイルが参照するヘッダファイルの読み込み＆処理は
一度しか走らないんです。想像以上に速くなりますよ。

自分の経験ですが、30万行のC++コードのビルドが2分で済みます(P3-800)。
.cppが700ファイル、.hが800ファイルでした。

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

DelphiやJava信者から言わせると、CやC++のインクルードファイルっていう仕様が腐ってるだけなんだよね。

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

プリコンパイル済みヘッダを意識すると

> で、全ての.cppファイルの先頭で
>
> #include "marugoto.hpp"

というやりかたになります。
(VC++つかってる人なら知ってると思いますが、
雛形の.cppファイルの先頭でstdafx.hを#includeしてるのがそれです)

逆に、コレがない環境(たとえばgcc)だと、includeするヘッダを
最低限にする必要があるんですよね。これがまた非常にめんどくさい。

STLなんかを使うには事実上必須だと思うんですけど、ねえ・・・

**849-850** · 02/11/03 21:34

>>851-853
丁寧なレスどうもｱﾘｶﾞ㌧。
漏れWindowsで開発したことがないんだわー。
カルチャーショック受けたので今度のボーナスで
VisualStudio.NET買ってみるわ。

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

そうじゃなくて、自分のモジュールがどのモジュールに
依存するのかを明示しろってことだろ。
その辺があいまいだと、際限なく他モジュールに依存しまくった挙句、
最終的にはどれがどれに依存しているのか分からなくなってしまうからな。

その辺がクリアなら、インクルードファイルをまとめるのもアリだと思うがな。
あとはコンパイル効率の問題だけだし(チーム全体で合意ができればOK)。
合意を形成しようって努力をするプログラマが少ないってのはそのとおりかも。
俺も含めて。

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

Windowsに関しては、"windows.h"が重過ぎるってのがあるかも。
適当なマクロきれば軽くなるんだけど、あんまりしないよね。

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

依存関係の明確化は難しいね。
本来は設計の段階でクリアになってなきゃならないんだけど、
ユーティリティー的なモジュールはついついおざなりになってしまう。

モジュールの初期化の順序って問題になりやすくないですか？

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

>>856
ふつう真っ先にPCHに入れます。むしろそのためのPCH。

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

つーか問題はコンパイル時間云々の問題じゃないんだけど。
雑魚はウザイから消えてくんない？

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

>>859
雑魚ってことで妥協するから
君の主張を書いてくれないか。
　
＃喧嘩じゃないだろ。

**名前は開発中のものです。** · 02/11/03 23:29

>>101
少しでもって･･･それってそんなに大仰な話なのか？
モジュール化について深く解説した本とか見たことないけど。

**名前は開発中のものです。** · 02/11/03 23:55

>>854
PCH に頻繁に書き換えるヘッダ、特に開発中のゲーム本体のヘッダを
突っ込むのは止めたほうが。フルビルドのときには早くなるけど、PCH
を作るのに時間かかるからインクリメンタルビルドが遅くなる。

俺は PCH には標準ヘッダと boost、それに変更の頻度は低いがプリ
コンパイルしときたいライブラリ関係のヘッダだけ読ませてる。ライ
ブラリは別のプロジェクト (*.dsp) に分離ね。

>>859
> つーか問題はコンパイル時間云々の問題じゃないんだけど。
設計の問題が重要なのは言うまでもないが、規模が大きくなるとファイルの
物理的な依存関係も無視できない要因になる。CPU は速くなったが I/O は
大して速くなってないから。

**名前は開発中のものです。** · 02/11/03 23:55

>>858
いや、windows.h(とMFC関係?)が大きすぎることがコンパイル時間を遅くしている最大の原因だってこと。
Hello Worldをウィンドウに表示するプログラムを作ってもコンパイル行数10万行ってどうよ？ってことで。

＞まずはヘッダファイルの一括インクルードする奴は駄目な奴だと
っていうこというなら、まず、windows.hとかから言うべきだよな。
(まぁ、OSってことで多少は意味合いが違うけど。)

で、pchってのは、そういう文化の上で必然的に生まれたものだって言うことをお忘れなく。

**名前は開発中のものです。** · 02/11/03 23:56

(というのは実はウソ。DOSのQuick C 1.0の時代から、インクリメンタルコンパイルは既に合ったしね。)
(Turbo Cもそういうのがウリだった。)

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

>>862
それなら、ディスクキャッシュに納まる程度なら問題ないという結論になりそうだ。

**名前は開発中のものです。** · 02/11/04 00:32

>>852
ハゲ同。
Delphiなら10万行くらいの再構築は10秒くらいで終わるし。

久々にVC++やgcc使って思うのはコンパイル遅いことだ
もうBorland製以外にはもどれん

**名前は開発中のものです。** · 02/11/04 00:32

>>865
充分なメモリを積んでもPCHにしたほうが速いよ。

ヘッダがいくら大量になろうと、PCHはほぼ一定の速度にしてしまうから
これの優秀さにコンパイラベンダは気づくべき。

**名前は開発中のものです。** · 02/11/04 00:37

>>867
プリコンパイル済みヘッダは、CodeWarriorにはたしかあるはず。
gccも3以降に動きがあると聞いたが...違うかも

**名前は開発中のものです。** · 02/11/04 01:48

なんでMSやBorlandが10年近くも前に実現してたpchが、
GCCにはないんだぁー！！

by PS2 プログラマー（GCCユーザー）

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

PS2のヘッダファイルもそんなに膨大な量あるの？
というか、G++のコンパイルの遅さ自体が問題なのかな。

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

>>861
ソフトウェア工学の薄くて高い本を読むと
構造化技法、モジュール強度やモジュール結合度について
6 ページくらいは書いてあるよ。

**名前は開発中のものです。** · 02/11/04 13:00

>>861
CODE COMPLETE と Writing Solid Code をセットでどうぞ。

>>870
PS2 標準のヘッダはまったく問題ない程度の量。ただ C++ で template を
多用し出すと、ちと気になるかな。（いろんな意味で）

**名前は開発中のものです。** · 02/11/04 23:35

>>872
　プロジェクト規模しだいでは「ちょっと」の領域は超えちゃうなぁ。
あと、一本上げて解ったんだけど、テンプレートはあんまりメモリに
優しくないので、中規模以上のプロジェクトではあんまり多用しない方が
いいような気がした。皆のトコではどーなんだろ？

どうでもいいけど、あんまりOOと関係ない流れだね。

**名前は開発中のものです。** · 02/11/04 23:50

この板だと「終了とゲームプログラミング」って感じだよな～

**名前は開発中のものです。** · 02/11/04 23:53

>>874　どうぞこちらへ
http://game.2ch.net/test/read.cgi/gamedev/1011082291/

**あぼーん** · NG

あぼーん

**逝って良しの１** ◆.CzKQna1OU · 02/11/05 00:00

test

**逝って良しの１** ◆MvRbZL6NeQ · 02/11/05 00:02

結論：
１）再利用可能モジュール以外は手続き型で書く
２）なるべく共通の部品て作れるように設計する。

純ＯＯは効率落とすだけ